WordPress.org

Make WordPress Core

Opened 13 years ago

Closed 13 years ago

#3678 closed defect (bug) (invalid)

Apache 2 segmentation fault

Reported by: mfauveau Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.1
Component: General Keywords:
Focuses: Cc:
PR Number:

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 (1)

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

Download all attachments as: .zip

Change History (18)

#1 @JeremyVisser
13 years ago

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

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?

#2 @foolswisdom
13 years ago

  • Milestone 2.1.1 deleted

#3 @mfauveau
13 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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.

#4 @ryan
13 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.

#5 follow-up: @foolswisdom
13 years ago

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

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.

#6 in reply to: ↑ 5 @mfauveau
13 years ago

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

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

#7 @westi
13 years ago

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

#8 @westi
13 years ago

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

Removing milestone and setting to invalid as no bug existed.

#9 @fwenzel
13 years ago

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

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.

#10 @foolswisdom
13 years ago

  • Milestone set to 2.2

fwenzel, can you get a stack trace back?

#11 @fwenzel
13 years ago

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.

#12 @fwenzel
13 years ago

  • Cc freeed@… added

#13 @fwenzel
13 years ago

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
13 years ago

Stack Backtrace for Apache / PHP4

#14 @fwenzel
13 years ago

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?

#15 @foolswisdom
13 years ago

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?

#16 @fwenzel
13 years ago

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

#17 @Nazgul
13 years ago

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

Not a Wordpress issue.

Note: See TracTickets for help on using tickets.