threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec

[freebsd at spatula.net]

The following reply was made to PR threads/84778; it has been noted by GNATS.

From: freebsd at spatula.net
To: Daniel Eischen <deischen at freebsd.org>
Cc: bug-followup at freebsd.org
Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling
 signals and Runtime.exec
Date: Thu, 6 Oct 2005 15:46:38 -0700 (PDT)

 select, however, does call nanosleep, and nanosleep does call 
 _nanosleep... but you're right that everything after that looks broken... 
 though I've never seen a stack get smashed like that before.  Usually I've 
 seen freakish addresses and "??" for function names, not addresses that 
 look reasonable and function names with symbols that can be actually 
 located.
 
 What happens when you gcore a running threaded process?  Do the process's 
 threads stop while the core dump is being written?  If not, could the 
 stack have changed while the core was being dumped and we're actually 
 seeing bits of stack from multiple running threads (and therefore 
 basically useless information)?
 
 Which thread do you see in a core dump if there are multiple threads?
 
 On Thu, 6 Oct 2005, Daniel Eischen wrote:
 
 > On Thu, 6 Oct 2005 freebsd at spatula.net wrote:
 >
 >> What about them is "not possible" exactly?
 >
 > Because [_]nanosleep() does not call pthread_setconcurrency().  And
 > pthread_setconcurrency() does not call pthread_mutexattr_init().
 >
 >> What about ktrace showing a tight loop of kse_release calls followed by
 >> RET kse_release 0?
 >>
 >> Why is it perfectly fine with libc_r?
 >
 > Libc_r is a totally different beast.  You can't necessarily compare
 > apples and oranges.  There are much more likely to be race conditions
 > exposed using libpthread than with libc_r.
 >
 > -- 
 > DE
 >