Ticket #3678 (closed defect (bug): invalid)

Opened 5 years ago

Last modified 5 years ago

Apache 2 segmentation fault

Reported by: mfauveau Owned by: anonymous
Priority: normal Milestone:
Component: General Version: 2.1
Severity: normal Keywords:
Cc: freeed@…

Description

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

Attachments

backtrace.24347 Download (13.8 KB) - added by fwenzel 5 years ago.
Stack Backtrace for Apache / PHP4

Change History

  • Status changed from new to closed
  • Resolution set to worksforme

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?

  • Milestone 2.1.1 deleted
  • Status changed from closed to reopened
  • Resolution worksforme deleted

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.

comment:4   ryan5 years ago

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.

comment:5 follow-up: ↓ 6   foolswisdom5 years ago

  • Priority changed from high to normal
  • Severity changed from blocker to normal
  • Milestone set to 2.3

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.

comment:6 in reply to: ↑ 5   mfauveau5 years ago

  • Status changed from reopened to closed
  • Resolution set to fixed

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 ;)

  • Status changed from closed to reopened
  • Resolution fixed deleted
  • Milestone 2.3 deleted
  • Status changed from reopened to closed
  • Resolution set to invalid

Removing milestone and setting to invalid as no bug existed.

  • Priority changed from normal to high
  • Status changed from closed to reopened
  • Resolution invalid deleted
  • Severity changed from normal to major

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.

  • Milestone set to 2.2

fwenzel, can you get a stack trace back?

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.

  • Cc freeed@… added

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.

fwenzel5 years ago

Stack Backtrace for Apache / PHP4

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?

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?

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

  • Priority changed from high to normal
  • Status changed from reopened to closed
  • Resolution set to invalid
  • Severity changed from major to normal
  • Milestone 2.2 deleted

Not a Wordpress issue.

Note: See TracTickets for help on using tickets.