Unkillable KSE threaded proc

Julian Elischer julian at elischer.org
Tue Sep 14 17:32:02 PDT 2004


andrew, if you get a chance, there is a patch at
  http://www.freebsd.org/~julian/q.diff
that has some debugging in it I'd like to see the result of..

if it crashes or hangs processes without triggerring the debugging code
then even that tells me something :-)


Andrew Gallatin wrote:

>FWIW, for the case where there is one lingering thread, calling
>thread_unsuspend_one() on it seems to get it to exit..
>
>Maybe there is some sort of race while exiting which causes the wrong
>number of threads to be either suspended, or unsuspended.  If too many
>are suspended, one is left lingering.  If too few are suspended, the
>system deadlocks because a thread never gets off the cpu.
>
>Would it help at all to try with libthr and see what it does?
>Let me know what more I can do to help get this fixed..
>
>Drew
>
>PS: 
>By "one lingering thread", I mean the case I first complained about.
>Eg:
>
>540 c164e700 e52e1000 1387     1   538 000c482 (threaded)  mx_pingpong
>   thread 0xc1fb8320 ksegrp 0xc15bb850 [SUSP]
>
>db> tr 540
>sched_switch(c1fb8320,0,0,15fc9814,e30bebc7) at sched_switch+0xd8
>mi_switch(1,0,e881fc44,c051e6dd,c1fb8320) at mi_switch+0x1c7
>thread_single(1,c06eaae0,e881fc64,c164e700,c1fb8320) at
>thread_single+0x1d7
>exit1(c1fb8320,9,0,e881fce4,c051877e) at exit1+0x115
>expand_name(c1fb8320,9,100,0,0) at expand_name
>postsig(9,202,c06e5dd8,17f,8058f84) at postsig+0x204
>ast(e881fd48) at ast+0x5e4
>doreti_ast() at doreti_ast+0x17
>db> call thread_unsuspend_one(0xc1fb8320)
>0xc1562640
><Happiness>
>
>
>  
>



More information about the freebsd-threads mailing list