Date: Mon, 1 Jul 2002 12:11:35 -0400 (EDT) From: Wesley Morgan <morganw@chemikals.org> To: <julian@elischer.org> Cc: <current@freebsd.org> Subject: Re: Post-KSE disaster with libc_r Message-ID: <20866.148.175.49.1.1025539895.squirrel@www.chemikals.org> In-Reply-To: <Pine.BSF.4.21.0207010013370.88707-100000@InterJet.elischer.org> References: <20020701024638.X11550-100000@volatile.chemikals.org> <Pine.BSF.4.21.0207010013370.88707-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ktracing with context switches look the same as before....
Stepping into libc_r leads me on a merry chase through what appears to be
normal execution, until somewhere in uthread_sig.c about line 552...
(gdb) r
Starting program: /usr/local/bin/kdeinit
Breakpoint 1 at 0x28e839f6: file
/usr/src/lib/libc_r/uthread/uthread_fork.c, line 49.Breakpoint 1, 0x28eda7d4 in fork () from /usr/lib/libc.so.5
(gdb) b /usr/src/lib/libc_r/uthread/uthread_sig.c:546
Breakpoint 2 at 0x28e8723d: file
/usr/src/lib/libc_r/uthread/uthread_sig.c, line 546.(gdb) c
Continuing.
Breakpoint 2, thread_sig_handle_special (sig=20)
at /usr/src/lib/libc_r/uthread/uthread_sig.c:546
546 for (pthread = TAILQ_FIRST(&_waitingq);
(gdb) print _waitingq
$1 = {tqh_first = 0x8054000, tqh_last = 0x8054210}
(gdb) s
0x28e8723e in thread_sig_handle_special (sig=20)
at /usr/src/lib/libc_r/uthread/uthread_sig.c:546
546 for (pthread = TAILQ_FIRST(&_waitingq);
Program received signal SIGSEGV, Segmentation fault.
0x28e8723e in thread_sig_handle_special (sig=20)
at /usr/src/lib/libc_r/uthread/uthread_sig.c:546
546 for (pthread = TAILQ_FIRST(&_waitingq);
Odd... Now if I set a breakpoint inside of the for() loop at line 552, it
will actually get past that:
Breakpoint 2, thread_sig_handle_special (sig=20)
at /usr/src/lib/libc_r/uthread/uthread_sig.c:552
552 pthread_next = TAILQ_NEXT(pthread, pqe);
(gdb) s
558 if (pthread->state == PS_WAIT_WAIT) {
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
thread_sig_handle_special (sig=20)
at /usr/src/lib/libc_r/uthread/uthread_sig.c:558
558 if (pthread->state == PS_WAIT_WAIT) {
(gdb) print pthread
$1 = (struct pthread *) 0x210
That definitely is not right!
Backing up, this is the content of the pthread struct before it gets
munched into 0x210 (re-ran the process of course)$1 = {magic = 3499860245,
name = 0x8056030 "_thread_initial", uniqueid = 0, lock = {access_lock = 686322256, lock_owner = 0, fname = 0x0, lineno = 0},
tle = {tqe_next = 0x0, tqe_prev = 0x28e94a88}, dle = {tqe_next = 0x0,
tqe_prev = 0x0}, start_routine = 0, arg = 0x0, stack = 0xbfb00000,
attr = { sched_policy = 3, sched_inherit = 0, sched_interval = 20000, prio = 15,
suspend = 0, flags = 0, arg_attr = 0x0, cleanup_attr = 0,
stackaddr_attr = 0xbfb00000, stacksize_attr = 1048576,
guardsize_attr = 4096}, ctx = {jb = {{_jb = {686343554, 686378132,
-1077939364, -1077939336, -1, 134561792, 4735, 0, 0, 0, 0, 0}}},
uc = {uc_sigmask = {__bits = {686343554, 686378132, 3217027932,
3217027960}}, uc_mcontext = {mc_onstack = -1, mc_gs = 134561792,
mc_fs = 4735, mc_es = 0, mc_ds = 0, mc_edi = 0, mc_esi = 0,
mc_ebp = 0, mc_isp = 0, mc_ebx = 0, mc_edx = 0, mc_ecx = 0,
mc_eax = 0, mc_trapno = 0, mc_err = 0, mc_eip = 0, mc_cs = 0,
mc_eflags = 0, mc_esp = 0, mc_ss = 0, mc_fpregs = {
0 <repeats 28 times>}, mc_flags = 0, __spare__ = {
0 <repeats 16 times>}}, uc_link = 0x0, uc_stack = {ss_sp = 0x0,
ss_size = 0, ss_flags = 0}, __spare__ = {0, 0, 0, 0, 0, 0, 0, 0}}},
curframe = 0x0, cancelflags = 4, continuation = 0, sigmask = {__bits = {0,
0, 0, 0}}, sigpend = {__bits = {0, 0, 0, 0}}, sigmask_seqno = 0,
check_pending = 0, state = PS_FDR_WAIT, last_active = 0, last_inactive = 0,
slice_usec = -1, wakeup_time = {tv_sec = -1, tv_nsec = -1}, timeout = 0,
error = 0, joiner = 0x0, join_status = {thread = 0x0, ret = 0x0, error =
0}, pqe = {tqe_next = 0x0, tqe_prev = 0x28e9a8d0}, sqe = {tqe_next =
0x0, tqe_prev = 0x0}, qe = {tqe_next = 0x0, tqe_prev = 0x28e97080}, data = {
mutex = 0x7, cond = 0x7, sigwait = 0x7, fd = {fd = 7, branch = 0,
fname = 0x0}, fp = 0x7, poll_data = 0x7, spinlock = 0x7, thread = 0x7},
poll_data = {nfds = 0, fds = 0x0}, interrupted = 0, signo = 0,
sig_defer_count = 0, yield_on_sig_undefer = 0, flags = 20,
base_priority = 15 '\017', inherited_priority = 0 '\0',
active_priority = 15 '\017', priority_mutex_count = 0, mutexq = {
tqh_first = 0x0, tqh_last = 0x8054254}, ret = 0x0, specific = 0x0,
specific_data_count = 0, cleanup = 0x0,
fname = 0x28e925a0 "/usr/src/lib/libc_r/uthread/uthread_read.c", lineno
= 81}
Of course all this means absolutely nothing to me :) ... Setting the
breakpoint just past the for() loop give me the same old crash as before:
#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 ?? ()
(gdb) print pthread
$2 = (struct pthread *) 0xffffffff
That's all I've got for now. Someone please tell me if posting this much
junk to -current is frowned upon. I'm looking for an old libc_r now, but
there could be some problems with the GCC changeout since DP1 that won't
work too well with KDE...
> 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.
>
>>
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?20866.148.175.49.1.1025539895.squirrel>