Thanks for the hints Rob. I'll have a look at this again as soon as I get the chance. It will be some time before I will have a chance to build a debug cygwin1.dll though. Steven
> -----Original Message----- > From: Robert Collins [mailto:[EMAIL PROTECTED]] > Sent: 21 February 2002 12:25 > To: O'BRIEN,STEVE (HP-UnitedKingdom,ex1); [EMAIL PROTECTED] > Subject: RE: ORBit install > > > > > > -----Original Message----- > > From: O'BRIEN,STEVE (HP-UnitedKingdom,ex1) > > > Hi Rob > > I didn't mean to suggest that there is a problem with the > > cygwin pthread > > implementation. > > There may be :}. I'm not concerned if there is or is not, but > rather with the fault you see - when we examine that we can > lay blame :}. > > > Sometimes I get: > > GThread-ERROR **: file gthread-posix.c: line 55 > > (g_mutex_new_posix_impl): > > error Device or resource busy during pthread_mutex_init > > ((pthread_mutex_t *) > > result, ((void *)0)) > > What does gthread-posix.c line 55 look like. > > > Sometimes I get a segmentation fault > > Can you duplicate this with gdb, or with strace, or with JIT > debugging (see how-debuging-works.txt in the cygwin source > directory.You'll need a debug cygwin1.dll for tracking this down. > > > Sometimes the test completes ok > > > > Failures appear at different points in the program, so I > > can't even say that > > the "resource busy" always occurs at X and segmentation fault > > always occurs > > at Y. > > Thats ok. If we can pin one down with a good backtrace, it > may make the fault visible. > > > When running in gdb the debug symbol table becomes corrupted, so the > > function names it reports do not match the file:lineno > > reported - so the > > program is clearly trashing memory on its way. > > Optimisation can also cause that, I wouldn't assume that the > symbol table is necessarily corrupt. What does bt full, and > info threads show? > > > I *think* that a mutex is not being set properly, or is being > > corrupted when > > the memory managment error kicks in, so that two threads > > attempt to free the > > same memory, or one uses memory that is already freed by > another. All > > guesswork though, because I have not been able to trace the > > execution in > > gdb. > > Yah, single stepping with threads is iffy at best, they tend > not do show the fault. Breakpoints are your friend :}. > > ROb >