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