Marc Ramirez wrote: >Thanks for looking! > >On Thursday 04 November 2004 03:47 pm, Julian Elischer wrote: > > >>> thread 0xc2081e10 ksegrp 0xc2154310 [SUSP] >>> thread 0xc187a960 ksegrp 0xc2154310 [SLPQ spltwt 0xc138fd98][SLP] >>> thread 0xc2156960 ksegrp 0xc2154310 [SUSP] >>> thread 0xc2157000 ksegrp 0xc2154310 [SUSP] >>> thread 0xc2157190 ksegrp 0xc2154310 [SLPQ select 0xc08e44c4][SLP][SUSP] >>> thread 0xc2156190 ksegrp 0xc2154310 [SLPQ accept 0xc216ae26][SLP][SUSP] >>> thread 0xc2156320 ksegrp 0xc187dc40 [SUSP] >>> >>> >>showing the output of >>show thread 0xc2081e10 >>(etc) >>for each thread >>should show the backtrace of each thread (I think) >> >> > >The output of this is at bottom. > > >>I suspect that all the threads are waiting for thread 0xc187a960 to wake >>up and suspend >>for some single-threading purpose. >>but it is hard to tell. >> >> I have committed a fix, can you try ? >davidxu 2004-11-04 22:13:16 UTC > > FreeBSD src repository > > Modified files: > sys/kern kern_thread.c > Log: > Don't forget to turn off P_SINGLE_BOUNDARY for thread_single(SINGLE_EXIT), > otherwise a threaded process which calls execv() will hang in kernel and > may can not be killed! > > Revision Changes Path > 1.205 +1 -1 src/sys/kern/kern_thread.c >Received on Thu Nov 04 2004 - 21:16:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:21 UTC