From owner-freebsd-stable@FreeBSD.ORG Wed Aug 13 14:56:15 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EA34106566C; Wed, 13 Aug 2008 14:56:15 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from proxypop2.sarenet.es (proxypop2.sarenet.es [194.30.0.95]) by mx1.freebsd.org (Postfix) with ESMTP id DBC308FC20; Wed, 13 Aug 2008 14:56:14 +0000 (UTC) (envelope-from BORJAMAR@SARENET.ES) Received: from [127.0.0.1] (matahari.sarenet.es [192.148.167.18]) by proxypop2.sarenet.es (Postfix) with ESMTP id 2687673126; Wed, 13 Aug 2008 16:56:11 +0200 (CEST) Message-Id: <0545482D-1E3F-4615-B3EB-04ABB838FF71@SARENET.ES> From: Borja Marcos To: Kris Kennaway In-Reply-To: <48A2E2AD.8060607@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 13 Aug 2008 16:56:28 +0200 References: <43EC06E9-76B3-4AA1-BC5E-4E1BD64AFC2D@SARENET.ES> <0296197A-28ED-4DAA-A31F-C28471E864FB@SARENET.ES> <20080812102856.GA6735@eos.sc1.parodius.com> <659A017B-5D6F-4B74-A85D-4A9A040CA442@SARENET.ES> <48A2DF31.4050907@FreeBSD.org> <48A2E2AD.8060607@FreeBSD.org> X-Mailer: Apple Mail (2.928.1) Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, Ivan Voras Subject: Re: umtxn and Apache 2.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 14:56:15 -0000 On Aug 13, 2008, at 3:33 PM, Kris Kennaway wrote: >> Hmm. Weird. I compiled the port having WITH_DEBUG defined (as I saw >> in the Makefile) and indeed the gcc invocations has the -g flag >> set. What is strange is the error gdb issued, offering a coredump, >> etc. > > It is likely that the binaries are stripped on install then. You > can try to run gdb against the compiled versions in the port work/ > directory. Doesn't seem stripped to me... %file /usr/local/sbin/httpd /usr/local/sbin/httpd: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.0 (700110), dynamically linked (uses shared libs), FreeBSD-style, not stripped %gdb /usr/local/sbin/httpd 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 conditions. 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) r Starting program: /usr/local/sbin/httpd [New LWP 100152] [New Thread 0x8102100 (LWP 100152)] (48)Address already in use: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down Unable to open logs Program exited with code 01. Any know bug affecting gdb on FreeBSD 7-STABLE/i386? "devilator" is mine, it's indeed compiled in debug mode, and gdb has problems to attach to it. It does it, but complains offering a core dump as well :/ %ps ax|fgrep devila 44336 p0- S 1:11.79 /usr/local/bin/devilator 67511 p0 R+ 0:00.00 fgrep devila %cd ~borjam/src/devilator-1.0a2/ %gdb -p 44336 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 conditions. 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". Attaching to process 44336 /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib- svr4.c:1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n /usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib- svr4.c:1443: internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) n Reading symbols from /usr/local/bin/devilator...done. Reading symbols from /lib/libkvm.so.4...done. Loaded symbols for /lib/libkvm.so.4 Reading symbols from /lib/libgeom.so.4...done. Loaded symbols for /lib/libgeom.so.4 Reading symbols from /lib/libdevstat.so.6...done. Loaded symbols for /lib/libdevstat.so.6 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libbsdxml.so.3...done. Loaded symbols for /lib/libbsdxml.so.3 Reading symbols from /lib/libsbuf.so.4...done. Loaded symbols for /lib/libsbuf.so.4 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 0x381510af in nanosleep () from /lib/libc.so.7 (gdb) bt #0 0x381510af in nanosleep () from /lib/libc.so.7 #1 0x3811f40a in sleep () from /lib/libc.so.7 #2 0x08048f4b in main () at devilator.c:47 (gdb) The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/local/bin/devilator, process 44336 >>> >>> Also, it is worth carefully checking your php configuration. For >>> example, php is notoriously sensitive to the order in which >>> modules are defined, and will crash or misbehave without giving >>> any other warnings if you don't meet its expectations. That may >>> or may not be relevant in your situation. >> Just in case I didn't change the order of the modules. I'll keep >> looking at it. > > This could be why :) Some people report that previously working > configurations stopped working after an upgrade until the ordering > was changed. Hmm. I see, I will check then. Thank you, Borja.