Date: Mon, 1 Jul 2002 00:24:58 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Wesley Morgan <morganw@chemikals.org> Cc: Bill Huey <billh@gnuppy.monkey.org>, Michael Nottebrock <michaelnottebrock@gmx.net>, freebsd-current@FreeBSD.ORG Subject: Re: Post-KSE disaster with libc_r Message-ID: <Pine.BSF.4.21.0207010013370.88707-100000@InterJet.elischer.org> In-Reply-To: <20020701024638.X11550-100000@volatile.chemikals.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 1 Jul 2002, Wesley Morgan wrote: > > Both the kdeinit and a child it forks are dying... Setting a breakpoint of > fork() in the binary shows: > > > Breakpoint 1, 0x28eda7d4 in fork () from /usr/lib/libc.so.5 > (gdb) bt > #0 0x28eda7d4 in fork () from /usr/lib/libc.so.5 > #1 0x28e83a5c in fork () from /usr/lib/libc_r.so.5 > #2 0x0804e8d5 in QGListIterator::~QGListIterator() () > #3 0x0804add1 in QGListIterator::~QGListIterator() () > (gdb) s > Single stepping until exit from function fork, > which has no line number information. > 0x28e83a5c in fork () from /usr/lib/libc_r.so.5 > (gdb) > Single stepping until exit from function fork, > which has no line number information. > warning: Cannot insert breakpoint 0: > Error accessing memory address 0xd0d0d0d0: Bad address. > (gdb) > > the 0xd0d0d0d0 is the same as in the coredump earlier. > > Rebuilt libc_r with debugging symbols and... > In the ktrace, an you show context switches? (add -w to both ktrace and kdump) Is this where is broke? it doesn't look much like the above.. > > (gdb) bt > #0 thread_kern_poll (wait_reqd=0) > at /usr/src/lib/libc_r/uthread/uthread_kern.c:862 > #1 0x28e8c8d7 in _thread_kern_scheduler () > at /usr/src/lib/libc_r/uthread/uthread_kern.c:372 > #2 0xd0d0d0d0 in ?? () > #3 0x00000001 in ?? () > #4 0x00005f28 in ?? () > Error accessing memory address 0xbecf2000: Bad address. > can you do what you did before and try singlestep a bit? also.. instead of checking out an older libc_r, can you try see if there is actually on old copy (say from teh DP1-image) somewhere and try that... it's possible we have symbol polution problemm.. a lot of the names in libc_r look awfully familliar from the KSE code.. (this shouldn;t be possible but.... > Hope some of this is useful to anyone out there! not on its own, but as a part of a developing picture. > > On Sun, 30 Jun 2002, Julian Elischer wrote: > > > Can someone please check out a libc_r tree as of 3 days ago > > and try that... > > > > There was a commit in libc_r/uthreads 2 days ago that might be relevant. > > failing that, can someone try newly compiled utilities on an older pre-KSE > > kernel? > > > > We need to eliminate one of these two changes... > > > > I think it's likely that it's breakage in signals from KSE > > but I'd like to know that before I tear even more hair out chasing this.. > > > > SO, I'm suffering from brain fade now.. > > but please, signals is known to be in dire need of cleanup > > after the KSE edit, (signals are delivered to processes but can effect > > individual threads. yuck) > > > > Anyone who can help identify the problem please do.. I'm off to bed before > > my head explodes.. > > I'll be back tomorrow AM. > > I'm going to spend as much of msuspension sleeping as possible :-) > > > > On Mon, 1 Jul 2002, Wesley Morgan wrote: > > > > > I see this problem too. Luckily I have my entire KDE and QT system build > > > with debugging symbols... However, the problem is definitely in the > > > libc_r... I get virtually the same dump as Michael. > > > > > > #0 0x28e8d280 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5 > > > #1 0x28e8c9a7 in _thread_kern_scheduler () from /usr/lib/libc_r.so.5 > > > #2 0xd0d0d0d0 in ?? () > > > #3 0x00000001 in ?? () > > > #4 0x00005f28 in ?? () > > > > > > > > > > > > On Sun, 30 Jun 2002, Bill Huey wrote: > > > > > > > On Mon, Jul 01, 2002 at 07:11:31AM +0200, Michael Nottebrock wrote: > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > > 0x281cc918 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5 > > > > > (gdb) bt > > > > > #0 0x281cc918 in _thread_kern_sched_state_unlock () from > > > > > /usr/lib/libc_r.so.5 > > > > > #1 0x281cc2e2 in _thread_kern_scheduler () from /usr/lib/libc_r.so.5 > > > > > #2 0xd0d0d0d0 in ?? () > > > > > #3 0x080570b0 in ?? () > > > > > > > > This is unlikely to be a KSE problem. > > > > > > > > What do the rest of the threads look like ? > > > > > > > > Try "info threads" in gdb and then progressively walking through the thread > > > > list with "thread N", N being the thread number. I ran into a funny > > > > create at thread start up time crash and I'm wondering if it could > > > > be the same thing. > > > > > > > > bill > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > > > > -- > > > _ __ ___ ____ ___ ___ ___ > > > Wesley N Morgan _ __ ___ | _ ) __| \ > > > morganw@chemikals.org _ __ | _ \._ \ |) | > > > FreeBSD: The Power To Serve _ |___/___/___/ > > > Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > -- > _ __ ___ ____ ___ ___ ___ > Wesley N Morgan _ __ ___ | _ ) __| \ > morganw@chemikals.org _ __ | _ \._ \ |) | > FreeBSD: The Power To Serve _ |___/___/___/ > Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0207010013370.88707-100000>