Very Computer

Howdy,

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.

--Cliff

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

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.

Quote:>How-To-Repeat:

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.

Quote:>Fix:

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.

Quote:>Release-Note:
>Audit-Trail:
>Unformatted: