On Thu, 12 Jun 2008, Jeremy Chadwick wrote: > > Yeah.. I have rebuilt lots of stuff, although not libc. > > Huh?
Sorry, I meant that I have to explicitly rebuilt it since I did a buildworld to make sure it wasn't fubar'd somehow. I haven't done that mainly because I find it extremely unlikely it would only break Apache in this manner but nothing else. I might rebuild it to get debug symbols though.. > > This machine has build world, kernel, KDE, etc.. I am pretty sure > > the hardware is OK as none of the builds had an issue. > > libc is part of world. *Every* program relies (is linked with) on > libc. Yes, sorry for my confusing turn of phrase! :) > > #10 0x08060c1f in main (argc=-716130182, argv=0x1) at > > http_main.c:5883 > > I can't say much about this, but I'm willing to bet it's the result > of some Apache + PHP weirdness. I've never known gdb on FreeBSD to > be as reliable/useful as, say, on Linux or Solaris. Always > odd/strange things happening with gdb on FreeBSD. Yeah :( > > I tried truss and it seemed to be taking a long time (5-10 minutes) > > and generating a lot of seemingly identical logging :( > > Okay, let's backtrack here. > > The OP states that he can induce a segfault of httpd when doing > "apachectl graceful". Is that the exact problem you're seeing, or > are you seeing problems where PHP/Apache segfaults during operation? > I just want to be clear. > > If the latter, then truss "generating lots of seemingly identical > logging" is probably expected. I'm guessing it's select() or poll() > or something related to kqueue/kevent, as it'd be waiting for I/O on > the HTTP socket. You'd have to submit the HTTP request to the PHP > script to get it to crash. > > In either case, you may have to resort to using ktrace + kdump, which > may or may not help narrow this down. > > Use "ktrace -i -t+ httpd -X" (I hope that'll work; I'm not sure if > ktrace allows you to pass arguments to a command), which will start > populating a file called ktrace.out. You should then do the > "apachectl graceful" in another window (or if the latter, submit the > HTTP request), and ktrace may exit when the segfault happens (I'm not > sure about this; it may sit there indefinitely). > > In the case it doesn't exit, and you've confirmed the core happened > (check "dmesg"), you should ^C the ktrace and then do "ktrace -C" > just to be sure nothing got wedged. > > You'll then have to use kdump to decode the contents of ktrace.out. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
signature.asc
Description: This is a digitally signed message part.
