Hello Mike, thanks for the fast response!
On Thu, Jul 19, 2007 at 07:39:35PM +0200, Mike Hommey wrote: > > #0 0xb7fd37f2 in ?? () > > #1 0xb7e37501 in raise () from /lib/i686/cmov/libpthread.so.0 > > #2 0xb5c41fb2 in nsProfileLock::FatalSignalHandler (signo=0xb) > > at nsProfileLock.cpp:206 > > #3 <signal handler called> > > #4 0xb7629b22 in rfc3484_sort () from /lib/i686/cmov/libc.so.6 > > #5 0xb759ce37 in msort_with_tmp () from /lib/i686/cmov/libc.so.6 > > #6 0xb759d048 in qsort () from /lib/i686/cmov/libc.so.6 > > #7 0xb7628fca in getaddrinfo () from /lib/i686/cmov/libc.so.6 > > #8 0xb7e6dfdf in PR_GetAddrInfoByName (hostname=0x9d76f84 > > "counter.yadro.ru", > > af=0x0, flags=0x8020) at prnetdb.c:2118 > > #9 0xb70e3969 in nsHostResolver::ThreadFunc (arg=0x810b658) > > at nsHostResolver.cpp:648 > > #10 0xb7e7af9c in _pt_root (arg=0x9fb2bb0) at ptthread.c:220 > > #11 0xb7e2f31b in start_thread () from /lib/i686/cmov/libpthread.so.0 > > #12 0xb76418ee in clone () from /lib/i686/cmov/libc.so.6 > > It looks like a crash in the libc... Is it reproducible at all ? Not any more. Yesterday it was. > > ii libc6 2.5-11 GNU C Library: Shared libraries > > What are you doing with libc6 2.5 on etch ? Well, using :) . > If you can reproduce the bug, please try to reproduce it with etch's > libc6. If it disappears, you'll know what the culprit is... I still have the core. Should we reassign the bug to libc6? With kind regards, -- Baurzhan Ismagulov http://www.kz-easy.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
