Apache 2 segmentation fault

[mfauveau]

With Wordpress 2.1 on Debian Sarge (stable) : Apache 2.0.54, PHP 4.3.10, MySQL 4.1.11.

Every hit on the blog generate exit signal segmentation fault (11) in Apache logs. Some times Apache even get frozen and doesn't serv any website while heating 95% of the CPU.

Only default modules are loaded in PHP.

I think it's a related to recent MySQL optimizations in WP 2.1

[JeremyVisser]

It is very unlikely that this is a WordPress problem. No PHP script should be able to crash a server. If something WordPress is doing (e.g. MySQL optimisation) happens to crash the server, it's not necessarily WordPress' fault.

For example, my friend's computer has a cracked motherboard. It still runs Windows XP and all the games he wants fine, but if we try to run Linux on it, it will usually crash within 20 minutes, and memtest86 will crash usually around 7% on Test number 2. It's not Linux's or memtest's fault that they happen to crash — it's just that Windows behaves differently, and happens to not trigger the fault that crashes it.

Can you reproduce this on another server, or on a freshly installed OS?

[mfauveau]

Well, I guess I don't like being wrong so I did a fresh install of Debian Sarge (stable) with the same packages on a virtual machine. So we have a fresh install on which I've setup ​http://www.wiik.fr, my website running WP 2.1.

I launch the site and reload it like 2 or 3 times. I check Apache error log and voila :

[notice] child pid 1162 exit signal Segmentation Fault (11)

Regards.

[ryan]

This can happen if WP goes into an infinite loop. I don't know how it is getting into one by just loading the front page. This is the only report I've seen of such behavior.

[foolswisdom]

mfauveau, can you get a stack trace back? Then we may be able to help, but as JeremyVisser described the problem is unlikely to be WordPress itself.

[mfauveau]

Replying to foolswisdom:

mfauveau, can you get a stack trace back? Then we may be able to help, but as JeremyVisser described the problem is unlikely to be WordPress itself.

Well, after upgrading PHP to 4.4.4 (dotdeb) and an apt-get upgrade, everything seems to work well. I think one dependency on the server was not met and a specific code in Wordpress was triggering it and generating the segmentation fault.

From now on, I see no segmentation fault in Apache, sweet !

Thanks for your help anyway guys and sorry to have bothered you ;)

[westi]

Removing milestone and setting to invalid as no bug existed.

[fwenzel]

Actually, I get the same segfault here. Same configuration (Debian stable) and after the upgrade to Wordpress 2.1 on three WP blogs running on the machine, Apache constantly segfaults and sometimes completely freezes as described above.

[foolswisdom]

fwenzel, can you get a stack trace back?

[fwenzel]

Yes, if you tell me how to make one? A core dump like this? ​http://httpd.apache.org/dev/debugging.html#crashes

I tried it and put it into gdb afterwards but all a "bt full" gives me is similar to this:

#10 0x00000070 in ?? ()
No symbol table info available.
#11 0x08403370 in ?? ()
No symbol table info available.
#12 0x4048e900 in ?? ()
No symbol table info available.
#13 0x4048df40 in ?? ()
No symbol table info available.
#14 0x4048e900 in ?? ()
No symbol table info available.

Any hints? Thanks.

[fwenzel]

Note: I have a core dump now, and unless somebody volunteers to analyze it, I have to rebuild Apache including the symbol tables so that we can actually make use of the backtrace. Will comment again when I did that.

[fwenzel]

Stack Backtrace for Apache / PHP4

[fwenzel]

I just added a stack backtrace. I made four of them but they look similar. However I can't read much useful out of this. Does this make more sense to somebody else?

[foolswisdom]

fwenzel, I looked at the stack trace and my searching did not immediately identify the problem. Most likely the problem is not WordPress. I did find out how this type of issue is generally investigated:
1) Search and then open a ticket with the distribution -- sounds like Debian in this case

• Maintainer may be able to identify the issue or provide next step in investigation
  

2) Try using a older package of PHP to help isolate when the the problem was introduced
3) Once isolated the maintainer may try and get you to apply individual patches

Please let us know what the upstream ticket # is?

[fwenzel]

Okay, I filed an upstream bug with Debian (​Bug 410549) and I hope I did it right ;)

[Nazgul]

Not a Wordpress issue.