Harald Braumann wrote: > On Tue, 23 Oct 2007 01:00:08 +0200 > Tomasz Sterna <[EMAIL PROTECTED]> wrote: > > >> Dnia 22-10-2007, Pn o godzinie 15:03 -0400, Ryan Pugatch pisze: >> >>> Yes, I did a make clean. Backtrace just has a bunch of stuff like: >>> >>> #0 0x00000030 in ?? () >>> #1 0x082456a0 in ?? () >>> #2 0x082456a0 in ?? () >>> #3 0x00c44158 in main_arena () from /lib/libc.so.6 >>> > The last output in sm's log was: > Mon Oct 22 09:34:38 2007 storage_db.c:161 serialising key time > Segmentation fault > > Try setting a breakpoint there (inside gdb type ``break > storage_db.c:161'') and then step from there on (whith ``next''). Maybe > you catch the faulting call this way. > > >> Looks like your glibc is stripped off symbols. >> Check if your distribution delivers -debug version of glibc. >> > > Hm, but even if glibc is stripped, there has to be one function in this > back trace that's inside sm and thus should be printed. > > Also, there are 256 lines in the bt. How do you get so > many nested function calls? AFAIK jabberd2 doesn't use any recursion ... > > Regards, > harry > _______________________________________________ > Jabberd2 mailing list > [email protected] > http://lists.xiaoka.com/listinfo.cgi/jabberd2-xiaoka.com >
(gdb) break storage_db.c:161 No source file named storage_db.c. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (storage_db.c:161) pending. (gdb) run Starting program: /usr/local/bin/sm [Thread debugging using libthread_db enabled] [New Thread -1208056128 (LWP 32684)] Error while reading shared library symbols: Cannot find new threads: generic error Breakpoint 2 at 0x111a44: file storage_db.c, line 161. Pending breakpoint "storage_db.c:161" resolved and then it hangs.... as does my jabber client when I try to connect _______________________________________________ Jabberd2 mailing list [email protected] http://lists.xiaoka.com/listinfo.cgi/jabberd2-xiaoka.com
