Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Jun 2008 16:35:26 +0930
From:      "Daniel O'Connor" <doconnor@gsoft.com.au>
To:        Jeremy Chadwick <koitsu@freebsd.org>
Cc:        freebsd-stable@freebsd.org, freebsd-apache@freebsd.org
Subject:   Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
Message-ID:  <200806121635.36998.doconnor@gsoft.com.au>
In-Reply-To: <20080612055919.GA27267@eos.sc1.parodius.com>
References:  <4846B64F.4090700@minibofh.org> <200806121445.30864.doconnor@gsoft.com.au> <20080612055919.GA27267@eos.sc1.parodius.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1909476.ZFXFlsEv8K
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thu, 12 Jun 2008, Jeremy Chadwick wrote:
> > I don't understand why gethostbyname() would call puts() - and why
> > that would then crash!
>
> I can't explain why it's calling puts() directly either.  Bad RAM
> could cause something bizarre like this, or a corrupt/broken binary.

Yeah.. I have rebuilt lots of stuff, although not libc.

This machine has build world, kernel, KDE, etc.. I am pretty sure the hardw=
are is OK as none of the builds had an issue.

> The libc code I'm looking at (src/lib/libc/net/gethostnameadr.c and
> gethostbydns.c) don't call puts) don't appear to call puts()
> directly. Of course, there may be macros used which do this.

I had a look - there certainly isn't anywhere obvious it's hapening. I gues=
s the only thing now is to rebuild with debugging.

> There are some places in the resolver code where printing to stdout
> or stderr can occur.  I'd expect to see a longer stack trace (meaning
> more functions between gethostbyname() and puts()) if that were the
> case, though.
>
> There's a decent document on how to debug httpd below.  You'll need
> to start httpd with -X or with "MaxClients 1", to keep it from
> forking. You can do that through gdb if you want, or (what I prefer,
> since I'm not very good with gdb) use truss.

OK thanks.

> http://httpd.apache.org/dev/debugging.html
>
> If you go the truss route, be sure to use -a -s 4096.  You'd be able
> to see what actual string is being output via puts(), assuming it
> gets as far as to start writing data to the fd.

Hmm I had a go with gdb but it doesn't work properly.. I got this..
[midget 16:33] /tmp/work/usr/ports/www/apache13-modssl/work/apache_1.3.41 >=
sudo gdb src/httpd
Password:
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain condition=
s.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
(gdb) run -X
Starting program: /data/tmp/work/usr/ports/www/apache13-modssl/work/apache_=
1.3.41/src/httpd -X
[New LWP 100212]
[New Thread 0x819d300 (LWP 100212)]
[New LWP 100212]
suspend error: generic error
[Switching to LWP 100212]
Stopped due to shared library event
(gdb) info thread
Cannot find new threads: generic error
(gdb) bt
#0  0x2807fda0 in r_debug_state () from /libexec/ld-elf.so.1
#1  0x2808367d in dlclose () from /libexec/ld-elf.so.1
#2  0x28706164 in zend_hash_apply_deleter ()
   from /usr/local/libexec/apache/libphp5.so
#3  0x287063a8 in zend_hash_graceful_reverse_destroy ()
   from /usr/local/libexec/apache/libphp5.so
#4  0x286fc89e in zend_shutdown () from /usr/local/libexec/apache/libphp5.so
#5  0x286bb5bf in php_module_shutdown () from /usr/local/libexec/apache/lib=
php5.so
#6  0x286bb66b in php_module_shutdown_wrapper ()
   from /usr/local/libexec/apache/libphp5.so
#7  0x28776aaa in apache_php_module_shutdown_wrapper ()
   from /usr/local/libexec/apache/libphp5.so
#8  0x080524d9 in ap_clear_pool (a=3D0x8106010) at alloc.c:1937
#9  0x0805f0f6 in standalone_main (argc=3DVariable "argc" is not available.
) at http_main.c:5480
#10 0x08060c1f in main (argc=3D-716130182, argv=3D0x1) at http_main.c:5883

I tried truss and it seemed to be taking a long time (5-10 minutes) and
generating a lot of seemingly identical logging :(

=2D-=20
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

--nextPart1909476.ZFXFlsEv8K
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (FreeBSD)

iD8DBQBIUMrA5ZPcIHs/zowRAu78AJ0YmAppa7JFaxyQ06SPy7gFgAO8PwCgqfRB
oZX+QiZ8daKQrmhahdTVfx8=
=tLwM
-----END PGP SIGNATURE-----

--nextPart1909476.ZFXFlsEv8K--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200806121635.36998.doconnor>