umtxn and Apache 2.2

[Borja Marcos]

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.