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.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
