This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: ORBit install


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:robert.collins@itdomain.com.au]
> Sent: 21 February 2002 12:25
> To: O'BRIEN,STEVE (HP-UnitedKingdom,ex1); cygwin-xfree@cygwin.com
> 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
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]