pro64-contrib
[Top] [All Lists]

Re: patch for wn_lower.cxx: bad deallocation of map ids

To: Chandrasekhar Murthy <murthy@xxxxxxx>
Subject: Re: patch for wn_lower.cxx: bad deallocation of map ids
From: David Goodwin <goodwin@xxxxxxxxxxxxx>
Date: Fri, 9 Mar 2001 11:15:14 -0800 (PST)
Cc: goodwin@xxxxxxxxxxxxx, pro64-contrib@xxxxxxxxxxx
In-reply-to: <3AA91F44.8B11F304@xxxxxxx>
References: <15015.64196.715282.473235@xxxxxxxxxxxxxxxxxxxxxx> <3AA91F44.8B11F304@xxxxxxx>
Reply-to: goodwin@xxxxxxxxxxxxx
Sender: owner-pro64-contrib@xxxxxxxxxxx
I've attached the program, but you won't be able to reproduce the problem
with it because exception handling is required (and actually it is easiest
to see when eh only partially enabled). It goes something like this:

1. function gslice::stride contains two regions, one for FUNC_ENTRY and one
   for an EH_CLEANUP of "a".

2. FUNC_ENTRY region assigned RID_map index of 1, EH_CLEANUP region
   assigned RID_map index of 0.

3. The lower replaces FUNC_ENTRY with another FUNC_ENTRY region, uses
   RID_map index of 1 for the new FUNC_ENTRY, but then frees index 1.

4. (this part I'm a little fuzzy on). When emitting whirl after optimizing,
   the optimizer generates a new map index for EH_CLEANUP, and since 1 is
   free, it uses that. So EH_CLEANUP's RID is stored at index 1.

5. optimizer then emits FUNC_ENTRY region, which has remembered RID_map
   index or 1, and so FUNC_ENTRY stores it's RID at index 1. So now both
   EH_CLEANUP and FUNC_ENTRY point to FUNC_ENTRY's RID.

6. Hit an assertion because EH_CLEANUP's RID (which is now incorrectly the
   same as FUNC_ENTRYs RID) is the wrong type (in
   region_util.cxx:REGION_is_EH).




class valarray
{
private:
  int buf[10];

public:
    valarray();
    valarray(const valarray& va);
    ~valarray();
};

valarray _M_stride;

    
class gslice
{
public:
    valarray stride () const;
    
private:
    bool _M_index;
};
    

valarray
gslice::stride () const
{
  valarray a = _M_index ? _M_stride : valarray();
  return a;
}



Chandrasekhar Murthy writes:
 > Hi David,
 > 
 > Could you send us the source program along with the commandline
 > options used to reproduce the problem you encountered.
 > 
 > Although your fix of commenting out the call to WN_Delete will
 > solve the problem, it will increase the working set as memory
 > will not be freed.
 > 
 > Thanks,
 > Murthy

<Prev in Thread] Current Thread [Next in Thread>