Re: Failure in class lookup

[Nicola Pero]

> > #0  0xfea9b3e0 in _lwp_sema_wait ()
> > #1  0xfecc9820 in _park ()
> > #2  0xfecc94f8 in _swtch ()
> > #3  0xfeccade8 in _mutex_adaptive_lock ()
> > #4  0xfeccb7e8 in pthread_mutex_lock ()
> > #5  0xfee60504 in __objc_mutex_lock ()
> > #6  0xfee609dc in objc_mutex_lock ()
> > #7  0xfee59c00 in objc_get_class ()
> >  
> > A number of calls from our code that led up to this ending.  So, it 
> > seems like the underlying mechanism that GNUstep is using to serialize 
> > class lookups is somehow failing and a lock is getting locked and never 
> > getting unlocked at that level.
> >  
> 
> I really don't understand much about locks/threading, but I might 
> suggest a few possible solutions.
> 
> 1 - In my experience, when compiling gcc on Solaris (at least 2.X 
> compilers), libobjc is not compiled with the -D_REENTRANT flag, even 
> when compiled with threading, which it should be. You might make sure 
> gcc/libobjc is compiled correctly. If you are using gnustep-objc, this 
> should be done automatically, but you might check to make sure.

Might be a Solaris specific problem, since on ix86 it seems to work well
under intensive threading (I've used it a lot with multithreading).

 
> 2 - gcc 3.x includes some changes to libobjc to avoid the mutex_lock 
> when doing class lookup.

Yes - gcc 3.1 ships with a libobjc which looks up classes without any
locking ... (Ravindra can also simply take libobjc/class.c from GCC 3.1
and import it into gnustep-objc, if he's using gnustep-objc - I think) but
maybe the bug will still appear somewhere else.

I'd be interested in more details (compiler version, runtime, platform,
eventual solution of the problem) if they become available.