This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
libobjc/9969: objc_msg_lookup is not thread safe
- From: ctm at ardi dot com
- To: gcc-gnats at gcc dot gnu dot org
- Cc: gavin at pokerpages dot com, ctm at ardi dot com
- Date: 5 Mar 2003 18:28:19 -0000
- Subject: libobjc/9969: objc_msg_lookup is not thread safe
- Reply-to: ctm at ardi dot com
>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
>Closed-Date:
>Last-Modified:
>Originator: ctm at ardi dot com
>Release: gcc 3.2.1
>Organization:
>Environment:
>Description:
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.
>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.
>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.
>Release-Note:
>Audit-Trail:
>Unformatted: