John, Thanks for your reply. I'm afraid my lack of c, gdb and linux debugging knowledge is letting me down here.
It appears that the attribute structure is allocated in the few lines just before the lock occurs. At first glance it does not appear that the program is trying to reuse the same structure on second run (it should be a new instance?). ( code snippet from mono_thread_get_stack_bounds) pthread_attr_t attr; guint8 *current = (guint8*)&attr; pthread_attr_init(&attr); pthread_getattr_np(pthread_self(),&attr); I'm going to try rebooting and stepping through the first (succesfull) run to see if I can trace what is happening with the attr structure on the first run - unless you have any other suggestions? > I've narrowed it down to a call in threads.c, line 766: > > pthread_getattr_np(pthread_self(), &attr). > > I'm still no wiser though. Does anyone have any insight as to why this > call might be causing some kind of deadlock? Look very carefully at what happens with that attribute resource structure. Is it getting re-used for the second call that causes the deadlock? How is it allocated? -- John Dallman Parasolid Porting Engineer Siemens PLM Software 46 Regent Street, Cambridge, CB2 1DP United Kingdom Tel: +44-1223-371554 [EMAIL PROTECTED] www.siemens.com/plm -- View this message in context: http://www.nabble.com/Can-run-mono-once-and-only-once-%28EEE-PC%29--tp18821807p19028825.html Sent from the Mono - General mailing list archive at Nabble.com. _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
