The THREADS_DISALLOW() in hash.cmod:138 ought to have hung in low_mt_lock_interpreter().
And do you know a solution to that problem ? Do you need something more from me ? If you want, you can add some debug temporary in CVS and I'll compile and run the test again.
As far as I can see, low_mt_lock_interpreter() does a simple mt_lock(&interpreter_lock), and if it succeeds twice the bug is in your threadlibrary.
/ David Gourdelier
/ Henrik Grubbström (Lysator)
Previous text:
2004-05-18 14:25: Subject: Re: Nettle cmod segfault
Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:
Anyway about the debug, I compiled with rtldebug but Pike doesn't seem to care much about it, at least I have the same output during the segfault. I uncomment VERBOSE_THREADS_DEBUG in pike_threadlib.h thought. Here is the result:
(Isn't the problem is that THREADS_DISALLOW is called 2 times without THREADS_ALLOW in between backend.cmod and hash.cmod ?)
The nesting looks correct, but it seems low_mt_lock_interpreter() succeeds twice.
The trace shows two threads, one in the backend, and one in Nettle:
backend.cmod:2333 THREADS_ALLOW() hash.cmod:138 THREADS_DISALLOW() hash.cmod:136 THREADS_ALLOW() backend.cmod:2340 THREADS_DISALLOW() hash.cmod:138 THREADS_DISALLOW()
The THREADS_DISALLOW() in hash.cmod:138 ought to have hung in low_mt_lock_interpreter().
And do you know a solution to that problem ? Do you need something more from me ? If you want, you can add some debug temporary in CVS and I'll compile and run the test again.
/ David Gourdelier
/ Brevbäraren