Date: Thu, 6 Oct 2005 23:00:20 GMT From: freebsd@spatula.net To: freebsd-threads@FreeBSD.org Subject: Re: threads/84778: libpthread busy loop/hang with Java when handling signals and Runtime.exec Message-ID: <200510062300.j96N0KoB042249@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR threads/84778; it has been noted by GNATS. From: freebsd@spatula.net To: Daniel Eischen <deischen@freebsd.org> Cc: bug-followup@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@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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510062300.j96N0KoB042249>