PR# 14471 Some callers of `urgent_plsc' do not protect passed object
Problem Report Summary
Submitter: prestoat2000
Category: Runtime
Priority: Medium
Date: 2008/06/15
Class: Bug
Severity: Serious
Number: 14471
Release: 6.2.73753
Confidential: No
Status: Open
Responsible:
Environment: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.8.1.14) Gecko/20080421 Firefox/2.0.0.14
OpenSolaris 2008.05 snv_90 on x86
Synopsis: Some callers of `urgent_plsc' do not protect passed object
Description
Based on code inspection only, it appears that bad things can happen if a routine calls `urgent_plsc' (in garcol.c) and does not protect the object whose address is passed via RT_GC_PROTECT, in the case of a multi-threaded application. In the MT case, `urgent_plsc' can block while synchronizing GC and then another thread may do a GC, thus possibly moving the object whose address was passed to urgent_plsc. If the caller did not protect the object, the pointer passed to urgent_plsc will then point at the old location of the object, which won't have been updated by the GC since the address of the C argument or local holding the object's address wasn't pushed onto loc_stack. Routines that can call urgent_plsc without protecting the object that is passed to it include: hrecord (hector.c) eremb (garcol.c) add_to_stack (malloc.c) If my analysis is correct, these routines should all use RT_GC_PROTECT and RT_GC_WEAN in the MT case. Otherwise, you can just close this report if I'm wrong.
To Reproduce
Problem Report Interactions