bug causes GNU objective-c runtime to not be thread-safe

bug causes GNU objective-c runtime to not be thread-safe

Post by c.. » Fri, 07 Mar 2003 03:57:44


There may be a few people in this group interested in the bug I just
submitted to the gcc folks.  I submitted it for gcc 3.2.1, but I
suspect the bug has been there a long time.

It appears to me that there's a race condition in objc_msg_lookup (the
routine that gcc uses for method invocation) that can cause a method
invocation to fail, but only under certain circumstances.

Anyone doing multi-threaded development using the objective-c runtime
should be concerned with this bug, *especially* if the code is
deployed on a multi-processor system.  I'm reasonably sure that the
Mac OS X objective-C runtime is different and won't have this bug.
I'm too lazy to check, especially when I know jcr is out and about.


>Number:         9969
>Category:       libobjc
>Synopsis:       objc_msg_lookup is not thread safe
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 05 18:36:00 UTC 2003

>Release:        gcc 3.2.1

objc_msg_lookup contains a race condition.  The code is:
result = sarray_get_safe...;
if (result == 0)
  if (receiver->class_pointer->dtable == __objc_uninstal...

The problem is that if two processors are hitting that code at roughly
the same time, one of them may see result is 0 but find that
receiver->class_pointer_dtable is not __objc_uninstalled_dtable,
because the thread on the other processor has patched it up to contain
the proper dtable entry for that class.


It's a narrow window of vulnerability, but we managed to get unlucky
and hit it by moving a threaded program from a uni-processor system to
a dual-processor system.  I don't think a test program would be
particularly useful for this bug.


I believe that particular race could be fixed by putting another call
to result = sarray_get_safe in the else portion and then only setting
result to __objc_get_forward_imp(op) if result is still 0.  Looking at
the code, I think there are similar races elsewhere.

- Show quoted text -



1. Any interest in the GNU objective-C runtime for dos?

I have managed to hand-compile the GNU Objective-C runtime
under DJGPP (gcc for dos) /gcc 2.4.1. (no performv:: support :(
so COLL won't work)

If sombody wants it, i'll upload it somewhere (you tell me
a good spot).  I'm going to send DJ Delore a note about it's
conspicous omission.

DJGPP can be found at grape.ecs.clarkson.edu:/pub/djgpp

   /\  /\                                |  Realism, n : Nature as seen through
  //\\//\\                               |               the eyes of a toad.
 //  \/  \\    A   C   B   E   T   H     |  --- Open locks
//        \\  ----------=====}=====O     |  --- Whoe'r knocks.  
"By the pricking of my thumbs,           |  I like my opinions, and you can't
 Something wicked this way comes!"       |  have them! Tpppppppppppbh!!!

2. Mpeg player for OS/2

3. GNU runtime environment for Objective-C

4. MSXML4.0 Critical Update

5. NeXT Objective-C vs. GNU Objective-C


7. GNU Objective C + Runtime on DOS?

8. the virus we thought we had--not now

9. Gnu EMACS and Objective-C ... i.e. Objective-C-mode.el

10. Solaris 8 threads: If a routine is Async-Signal-Safe is it also thread Safe?

11. thread-safe and signal-safe

12. Is Async-signal-safe the same as thread-safe?

13. Thread-safe and "Signal-safe"