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.
>Synopsis: objc_msg_lookup is not thread safe
>Arrival-Date: Wed Mar 05 18:36:00 UTC 2003
>Release: gcc 3.2.1
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 unluckyQuote:>How-To-Repeat:
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 callQuote:>Fix:
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.