Chrome Err Empty Response occasionally when going to homepage

Posted January 10, 2020 4.7k views

Up until recently, I have been seeing on chrome erremptyresponse when going to my website homepage. It rarely happens, but lately it has been noticeably happening more frequently.

After refreshing a few times it comes back.

In the error logs I can see a few of the following lines:

child pid 23559 exit signal Segmentation fault (11), possible coredump in /etc/apache2

Using wordpress on apache and ubuntu, with W3 total cache and Autoptimize.

Can anyone recommend any action that might help with this?

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
3 answers


I could suggest a few things:

  • If you do not want to spend time investigating this straight away, try to upgrade your Apache, PHP, Wordpress version along with all plugins and see if the problem persists.

  • If this does not help, then you would need to enable core dumps for your Apache instance and then analyze the core dumps

If you need to do that, here’s what you would have to do:

  1. SSH to your Droplet

  2. Edit the following file


And change enabled from “0” to a “1” so it looks like this.

Note, for more information about Apport check out the official documentation here.

  1. Then edit your apache config apache2.conf and add the following:
CoreDumpDirectory /tmp/apache2-core-dump
  1. Create that directory and make sure Apache can write to the file:
sudo mkdir  /tmp/apache2-core-dump
sudo chmod 777 /tmp/apache2-core-dump
  1. Remove the file size limit:
ulimit -c unlimited
  1. Than try to cause the segmentation fault again and you should see a core dump popup in the /tmp/apache2-core-dump directory.

  2. After that to analyze the core dump use the gdb command:

gdb apache2 /tmp/apache2-core-dump/coredump-TIMESTAMP

Right after this, to see stack trace details, in gdb run:

  • where

This would give you more information on what’s causing the segmentation fault.

Hope that this helps!

  • Hi Bobby, I have carried out your instructions and enabled core dumps
    The problem happened again a few moments ago, possible core dump in /tmp/apache2-core-dumps
    However there is no core dump in there.
    Kind Regards

    • Hello,

      What I could suggest is checking your /var/crash/ folder as well.

      If this is empty try to enable Apport. You can do that by running:

      sudo systemctl enable apport.service

      After that in case that you need to disable it you could rin:

      sudo systemctl disable apport.service

      For more information you could also check the official documentation for Apport here:

      Let me know how it goes!


      • Hi Bobby
        There’s a file named “usrsbin_apache2.33.crash”
        Should I nano this or use the afforementioned gdb command?
        Best Regards

        • Hi Matt,

          I believe that you would need to use the gdb command in order to be able to extract the information from the dump.

          Let me know how it goes!

          • Hi Bobby
            It comes up with the following:
            “/var/crash/usrsbin_apache2.33.crash” is not a core dump: File format not recognized

            Instead, I nano-ed the file and it shows the below.

            ProblemType: Crash
            Architecture: amd64
            CrashCounter: 1
            Date: Mon Feb 3 10:07:03 2020
            DistroRelease: Ubuntu 16.04
            ExecutablePath: /usr/sbin/apache2
            ExecutableTimestamp: 1570571756
            ProcCmdline: /usr/sbin/apache2 -k start
            ProcCwd: /tmp/apache2-core-dump
            PATH=(custom, no user)

            It then has a long list of process details.

            Thereafter some details about ProcStatus and then it says Coredump: base64 and considerably large amounts of numbers and letters which slow the terminal down when rendering.

          • Hi Matt,

            Sorry, I should have provided you with a bit more information. You can unpack apport crash file. And then use only CoreDump dump with gdb as usual.

            To do that you need to run the following:

            • Unpack the crash file:
            apport-unpack usrsbin_apache2.33.crash some_directory_here
            • Then cd to the some_directory_here directory:
            cd some_directory_here
            • Then use the gdb command:
            gdb $(cat ExecutablePath) CoreDump 

            Finally as mentioned you could run bt in order to back-trace the output.


          • Hi Bobby, Here’s the result of the unpack and gdb on the crash file

            [New LWP 22984]
            [Thread debugging using libthread_db enabled]
            Using host libthread_db library "/lib/x86_64-linux-gnu/".
            Core was generated by `/usr/sbin/apache2 -k start'.
            Program terminated with signal SIGILL, Illegal instruction.
            #0  0x00007f12c65efedc in _xend () at pthread_rwlock_unlock.c:38
            38      pthread_rwlock_unlock.c: No such file or directory.
            (gdb) where
            #0  0x00007f12c65efedc in _xend () at pthread_rwlock_unlock.c:38
            #1  __GI___pthread_rwlock_unlock (rwlock=0x7f12ae5c1088) at pthread_rwlock_unlock.c:38
            #2  0x00007f12bd74b519 in apc_lock_wunlock () from /usr/lib/php/20151012/
            #3  0x00007f12bd74e5f2 in apc_cache_insert () from /usr/lib/php/20151012/
            #4  0x00007f12bd74ea3d in apc_cache_store () from /usr/lib/php/20151012/
            #5  0x00007f12bd74ba44 in ?? () from /usr/lib/php/20151012/
            #6  0x00007f12c2fe444d in ?? () from /usr/lib/apache2/modules/
            #7  0x00007f12c2f9fa4b in execute_ex () from /usr/lib/apache2/modules/
            #8  0x00007f12c2ff4077 in zend_execute () from /usr/lib/apache2/modules/
            #9  0x00007f12c2f5f033 in zend_execute_scripts () from /usr/lib/apache2/modules/
            #10 0x00007f12c2efdf40 in php_execute_script () from /usr/lib/apache2/modules/
            #11 0x00007f12c2ff59f2 in ?? () from /usr/lib/apache2/modules/
            #12 0x00005556a5c64260 in ap_run_handler ()
            #13 0x00005556a5c647e6 in ap_invoke_handler ()
            #14 0x00005556a5c7bb52 in ap_process_async_request ()
            #15 0x00005556a5c7bd00 in ap_process_request ()
            #16 0x00005556a5c77f3e in ?? ()
            #17 0x00005556a5c6e210 in ap_run_process_connection ()
            #18 0x00007f12c35457e9 in ?? () from /usr/lib/apache2/modules/
            #19 0x00007f12c3545a64 in ?? () from /usr/lib/apache2/modules/
            #20 0x00007f12c354687f in ?? () from /usr/lib/apache2/modules/
            #21 0x00005556a5c4688e in ap_run_mpm ()
            #22 0x00005556a5c3f740 in main ()
          • Hi Matt,

            That’s interesting, it seems like an issue with either Apache MPM or PHP APCu.

            As a quick test, you could try upgrading your current PHP 7.0 version to 7.2+ and see if the issue persists.

            Also try upgrading Apache.

            Another thing that you could try is to disable APCu and test it that way.

            My suspicion is that it would either be a problem with the framework/plugin so you might want to bring this up to vendor’s attention. Or if the issue still persists I would recommend reporting a bug here.

            Hope that this helps! Let me know how it goes!

Hi Bobby
The result of your answer gives the following output

[Thread debugging using libthreaddb enabled]
Using host libthread
db library “/lib/x8664-linux-gnu/”.
Core was generated by `/usr/sbin/apache2 -k start’.
Program terminated with signal SIGILL, Illegal instruction.
# 0 0x00007f12c65efedc in xend () at pthreadrwlockunlock.c:38
38 pthread
rwlock_unlock.c: No such file or directory.