Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
On Sat, 4 Jan 2003, Robert Watson wrote: Juli Mallett pointed me at the following reproduceable problem on my -current notebook with userland/kernel dated Dec 29: paprika:~/freebsd/test/pthread ./test 1 2 1 2 1 2 load: 0.02 cmd: test 910 [running] 0.00u 0.01s 0% 824k 1 Bus error (core dumped) paprika:~/freebsd/test/pthread ./test 1 2 load: 0.23 cmd: test 914 [running] 0.00u 0.01s 0% 824k 1 Bus error (core dumped) Hitting ^T to get status information seems to break output following the first printf after the information display. Here's the stack trace from the test program from the first execution above: This fixes the problem for me: -- Dan Eischen Index: uthread/uthread_init.c === RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_init.c,v retrieving revision 1.44 diff -u -r1.44 uthread_init.c --- uthread/uthread_init.c 6 Jan 2003 00:56:23 - 1.44 +++ uthread/uthread_init.c 10 Jan 2003 20:27:05 - @@ -220,7 +220,7 @@ _pthread_page_size = getpagesize();; _pthread_guard_default = _pthread_page_size; - sched_stack_size = _pthread_page_size; + sched_stack_size = 4 * _pthread_page_size; _pthread_attr_default.guardsize_attr = _pthread_guard_default; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
In message: [EMAIL PROTECTED] Robert Watson [EMAIL PROTECTED] writes: : assuming it's something about poor signal handling in libc_r, actually. I've seen signal problems in devd after it forks a child. Before it forks a child ^C works, but after it does a system(3) to run a command, ^C no longer works. There's something really odd going on that I've not had time to figure it out. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
On Sat, 4 Jan 2003, Robert Watson wrote: Juli Mallett pointed me at the following reproduceable problem on my -current notebook with userland/kernel dated Dec 29: paprika:~/freebsd/test/pthread ./test ... load: 0.23 cmd: test 914 [running] 0.00u 0.01s 0% 824k 1 Bus error (core dumped) Hitting ^T to get status information seems to break output following the first printf after the information display. Here's the stack trace from the test program from the first execution above: This caused a reproducible kernel panic for a null pointer bug in ttyinfo() here, but seemed to work right once I fixed the panic. (The panic was just a bug in my unbreaking of the calculation of rss.) Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
On Saturday, January 4, 2003, at 06:00 PM, Robert Watson wrote: On Sat, 4 Jan 2003, Juli Mallett wrote: * De: Robert Watson [EMAIL PROTECTED] [ Data: 2003-01-04 ] [ Subjecte: pthread ^T problem on recent -CURRENT: death in libc_r mutex ] Juli Mallett pointed me at the following reproduceable problem on my -current notebook with userland/kernel dated Dec 29: Incidentally, this doesn't illustrate the problem I was actually trying to point out. Try making the sleep's pthread_yield(). That will make the threads never run again. sleep is the hack I've had to do. In my appp, I have a 'my_yield' function which will sleep on FreeBSD, and yield on everywhere else :( Hmm. I'm not experiencing that problem -- if I replace the sleep() with pthread_yield(), I get a long sequence of '1's until thread2 is started, and then clean alternation between '1' and '2'. I don't see any failure to schedule a thread after it has yielded. I'm updating my box from Dec 29 to today to see if that makes a difference either way on either problem. With pthread_yield() I get the same as Watson. It still core's with a few ctrl-T's. I'm running today's source. -DR To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
On Sat, 4 Jan 2003, Juli Mallett wrote: * De: Robert Watson [EMAIL PROTECTED] [ Data: 2003-01-04 ] [ Subjecte: pthread ^T problem on recent -CURRENT: death in libc_r mutex ] Juli Mallett pointed me at the following reproduceable problem on my -current notebook with userland/kernel dated Dec 29: Incidentally, this doesn't illustrate the problem I was actually trying to point out. Try making the sleep's pthread_yield(). That will make the threads never run again. sleep is the hack I've had to do. In my appp, I have a 'my_yield' function which will sleep on FreeBSD, and yield on everywhere else :( Updating to Jan 4 kernel generates the same failure mode for me: following a ^T, I get a core dump. If I run it outside of gdb and then run gdb on the core dump, I get the following: (gdb) bt #0 0x2807aa63 in _mutex_cv_lock () from /usr/lib/libc_r.so.5 #1 0x2807a749 in pthread_mutex_unlock () from /usr/lib/libc_r.so.5 #2 0x28136164 in funlockfile () from /usr/lib/libc.so.5 #3 0x2812c6ab in vfprintf () from /usr/lib/libc.so.5 #4 0x2811ab82 in printf () from /usr/lib/libc.so.5 #5 0x08048611 in thread1 (arg=0x0) at test.c:12 #6 0x280732ce in _thread_start () from /usr/lib/libc_r.so.5 There's a bit more noise if I run it under gdb, since gdb picks up the SIGINFO delivery (twice?) but the same result occurs in the end: 1load: 0.07 cmd: test 690 [running] 0.04u 0.20s 0% 816k Program received signal SIGINFO, Information request. 0x280d4c83 in poll () from /usr/lib/libc.so.5 (gdb) cont Continuing. Program received signal SIGINFO, Information request. 0x280d4c83 in poll () from /usr/lib/libc.so.5 (gdb) cont Continuing. Program received signal SIGBUS, Bus error. [Switching to Process 690, Thread 4] 0x2807aa63 in _mutex_cv_lock () from /usr/lib/libc_r.so.5 (gdb) trace trace command requires an argument (gdb) bt #0 0x2807aa63 in _mutex_cv_lock () from /usr/lib/libc_r.so.5 #1 0x2807a749 in pthread_mutex_unlock () from /usr/lib/libc_r.so.5 #2 0x28136164 in funlockfile () from /usr/lib/libc.so.5 #3 0x2812c6ab in vfprintf () from /usr/lib/libc.so.5 #4 0x2811ab82 in printf () from /usr/lib/libc.so.5 #5 0x08048611 in thread1 (arg=0x0) at test.c:12 #6 0x280732ce in _thread_start () from /usr/lib/libc_r.so.5 (gdb) Either way, still not the symptoms you have, but equally fatal. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
On Sun, 5 Jan 2003, Robert Watson wrote: Updating to Jan 4 kernel generates the same failure mode for me: following What makes you think it's the kernel? a ^T, I get a core dump. If I run it outside of gdb and then run gdb on the core dump, I get the following: To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
On Sun, 5 Jan 2003, Julian Elischer wrote: On Sun, 5 Jan 2003, Robert Watson wrote: Updating to Jan 4 kernel generates the same failure mode for me: following What makes you think it's the kernel? Well, to be more precise, I upgraded the entire system to Jan 4. I'm assuming it's something about poor signal handling in libc_r, actually. a ^T, I get a core dump. If I run it outside of gdb and then run gdb on the core dump, I get the following: Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
* De: Robert Watson [EMAIL PROTECTED] [ Data: 2003-01-04 ] [ Subjecte: pthread ^T problem on recent -CURRENT: death in libc_r mutex ] Juli Mallett pointed me at the following reproduceable problem on my -current notebook with userland/kernel dated Dec 29: Incidentally, this doesn't illustrate the problem I was actually trying to point out. Try making the sleep's pthread_yield(). That will make the threads never run again. sleep is the hack I've had to do. In my appp, I have a 'my_yield' function which will sleep on FreeBSD, and yield on everywhere else :( -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet. OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pthread ^T problem on recent -CURRENT: death in libc_r mutex
On Sat, 4 Jan 2003, Juli Mallett wrote: * De: Robert Watson [EMAIL PROTECTED] [ Data: 2003-01-04 ] [ Subjecte: pthread ^T problem on recent -CURRENT: death in libc_r mutex ] Juli Mallett pointed me at the following reproduceable problem on my -current notebook with userland/kernel dated Dec 29: Incidentally, this doesn't illustrate the problem I was actually trying to point out. Try making the sleep's pthread_yield(). That will make the threads never run again. sleep is the hack I've had to do. In my appp, I have a 'my_yield' function which will sleep on FreeBSD, and yield on everywhere else :( Hmm. I'm not experiencing that problem -- if I replace the sleep() with pthread_yield(), I get a long sequence of '1's until thread2 is started, and then clean alternation between '1' and '2'. I don't see any failure to schedule a thread after it has yielded. I'm updating my box from Dec 29 to today to see if that makes a difference either way on either problem. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
