Related

Subdomain with different DocumentRoot Question Question
You don't have permission to access / on this server. Wordpress multiple sites Ubuntu Question Question

Question

Chrome Err Empty Response occasionally when going to homepage

Posted January 10, 2020 3.1k views
ApacheWordPress

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?
Thanks

Add a comment
matt41f5576fd18eff1f5bf8ed
By:
matt41f5576fd18eff1f5bf8ed

Related

Subdomain with different DocumentRoot Question Question
You don't have permission to access / on this server. Wordpress multiple sites Ubuntu Question Question

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.

×
2 answers
bobbyiliev January 10, 2020

Hello,

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

/etc/default/apport

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!
Regards,
Bobby

Reply Report
  • matt41f5576fd18eff1f5bf8ed January 30, 2020

    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

    Reply Report
    • bobbyiliev February 2, 2020

      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:

      https://wiki.ubuntu.com/Apport

      Let me know how it goes!

      Regards,
      Bobby

      Reply Report
      • matt41f5576fd18eff1f5bf8ed February 3, 2020

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

        Reply Report
        • bobbyiliev February 3, 2020

          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!
          Regards,
          Bobby

          Reply Report
          • matt41f5576fd18eff1f5bf8ed February 3, 2020

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

            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
            ProcEnviron:
            PATH=(custom, no user)
            LANG=C
            ProcMaps:

            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.

            Reply Report
          • bobbyiliev February 3, 2020

            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.

            Regards,
            Bobby

            Reply Report
          • matt41f5576fd18eff1f5bf8ed February 7, 2020

            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/libthread_db.so.1".
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/apcu.so
#3  0x00007f12bd74e5f2 in apc_cache_insert () from /usr/lib/php/20151012/apcu.so
#4  0x00007f12bd74ea3d in apc_cache_store () from /usr/lib/php/20151012/apcu.so
#5  0x00007f12bd74ba44 in ?? () from /usr/lib/php/20151012/apcu.so
#6  0x00007f12c2fe444d in ?? () from /usr/lib/apache2/modules/libphp7.0.so
#7  0x00007f12c2f9fa4b in execute_ex () from /usr/lib/apache2/modules/libphp7.0.so
#8  0x00007f12c2ff4077 in zend_execute () from /usr/lib/apache2/modules/libphp7.0.so
#9  0x00007f12c2f5f033 in zend_execute_scripts () from /usr/lib/apache2/modules/libphp7.0.so
#10 0x00007f12c2efdf40 in php_execute_script () from /usr/lib/apache2/modules/libphp7.0.so
#11 0x00007f12c2ff59f2 in ?? () from /usr/lib/apache2/modules/libphp7.0.so
#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/mod_mpm_prefork.so
#19 0x00007f12c3545a64 in ?? () from /usr/lib/apache2/modules/mod_mpm_prefork.so
#20 0x00007f12c354687f in ?? () from /usr/lib/apache2/modules/mod_mpm_prefork.so
#21 0x00005556a5c4688e in ap_run_mpm ()
#22 0x00005556a5c3f740 in main ()
            Reply Report
          • bobbyiliev February 7, 2020

            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!
            Regards,
            Bobby

            Reply Report
matt41f5576fd18eff1f5bf8ed February 7, 2020
[deleted]
Reply Report
matt41f5576fd18eff1f5bf8ed February 7, 2020

Hi Bobby
The result of your answer gives the following output

[Thread debugging using libthreaddb enabled]
Using host libthreaddb library “/lib/x8664-linux-gnu/libthreaddb.so.1”.
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 pthreadrwlock_unlock.c: No such file or directory.

Reply Report
Submit an Answer

Related

Looking for something else?

Ask a new question Search for more help