[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Failure in class lookup
From: |
Nicola Pero |
Subject: |
Re: Failure in class lookup |
Date: |
Fri, 21 Jun 2002 16:14:00 +0100 (BST) |
> > #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.