[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Failure in class lookup
From: |
Adam Fedor |
Subject: |
Re: Failure in class lookup |
Date: |
Fri, 21 Jun 2002 08:43:48 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.0rc2) Gecko/20020513 |
Ravindra wrote:
#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.
2 - gcc 3.x includes some changes to libobjc to avoid the mutex_lock
when doing class lookup.
--
Adam Fedor, Digital Optics Corp. | I'm glad I hate spinach, because
http://www.doc.com | if I didn't, I'd eat it, and you
| know how I hate the stuff.