|
First (idle) question - why are you running a debugging
version of glibc?
Second:
(gdb) info
stack
#0 0x0050f402 in __kernel_vsyscall () #1 0x0071a1f8 in raise () from /lib/libc.so.6 #2 0x0071b948 in abort () from /lib/libc.so.6 #3 0x0074f52a in __libc_message () from /lib/libc.so.6 #4 0x007d0565 in __chk_fail () from /lib/libc.so.6 #5 0x00f8b474 in initDevices () from /usr/lib/libntop-3.1.so
Boy, that's totally useless isn't it! Hello - gdb - give me information - hellooooo is anybody there....
OK... try this:
(gdb) frame 5 (gdb) list
hopefully, that will show WHICH line of the 211 in initDevices is causing some kind of error check in glibc to be tripped. Otherwise, you will have to add a bunch of traceEvent() calls and use that to see where it's bombing. I usually use this, added at the end of ntop.h:
#define
traceEventTemp(fmt, ...) { \
and then code
traceEventTemp("%s", "text");
Before/after every branch or even every line...
(you MUST use two parameters - the macro isn't smart enough to handle none, while the normal traceEvent() does)
-----Burton
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Randy Gordey [EMAIL PROTECTED] ~]# gdb ntop GNU gdb Red Hat Linux (6.3.0.0-1.21rh) 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-redhat-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1".
<snip />
|
_______________________________________________ Ntop-dev mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
