In the last episode (Nov 04), Marc Ramirez said: > On Thursday 04 November 2004 09:36 am, Mike Makonnen wrote: > > Hmm, looks like the application is using libthr and not libpthread. > > I'll take a look at it, but in the mean time you might want to map > > libthr and libc_r to libpthread in libmap.conf(5). > > > > Can all other users with this problem verify which threading > > library they're running? You can use the following command on the > > binary. For example: # ldd /path/to/binary > > Not me. Thanks! I just noticed this on my machine as well (SMP, 5.3-stable as of yesterday), running a testsuite program linked to libpthreads. It creates 10 threads whose only job is to fork(), exec /bin/sleep, kill -9 the child, and wait for the status. Each thread does this 1000 times in a tight loop. Occasionally the whole thing will end up STOPped, but resumes within 60 seconds. If I ktrace the process during this, I see a long delay followed by: 39117 pike RET fork 0 32592 pike RET fork 39117/0x98cd Could there be a race or deadlock within the kernel's fork() routines? What happens if two threads on different CPUs decide to fork at the same time? -- Dan Nelson dnelson_at_allantgroup.comReceived on Thu Nov 04 2004 - 21:28:41 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:21 UTC