[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: KJS crashes
From:       Dirk Mueller <mueller () kde ! org>
Date:       2001-08-01 11:50:09
[Download RAW message or body]

On Mit, 01 Aug 2001, Harri Porten wrote:

> > > The patch makes obviously sense, please apply (calling a virtual method 
> > > without a full constructor run before can't work).  
> > Actually, after having slept a night over it I don't understand anymore why 
> > it is supposed to work.
> Heh. Now *I* don't feel so stupid anymore :) There is no "virtual method"
> involved as far as I see it btw.

its the virtual method "mark()", that is run in the gc during the 
mark-phase. I thought that it is possible to happen that the collector tries 
to mark a memory allocation where the Imp derivative constructor didn't 
fully run yet and this causes multiple problems.

But actually this seems to be impossible to me. the Imp constructor doesn't 
do anything, and as soon as it is done there is at least a somehow valid 
virtual method pointer (it doesn't point to the correct derivative class 
pointer but that shouldn't hurt too much). Additionally the crash happened 
in allocate() and not in "garbled place / collect()" which gives me another 
set of headaches, so I think we didn't fix it yet we just made it less 
reproduceable somehow. the setCreated(true) int he Imp constructor doesn't 
make sense to me. we should move that to the overloaded operator new 
function instead (which breaks BC though). 

That reminds me again that I still have to buy Scott Mayers because IIRC 
there are some advices about gc's with C++ in there ;-)

> > Isn't the actual problem that we allocate another Imp derivative during 
> > executing an Imp derived constructor ?
> That certainly happens in many cases but I don't understand why this
> causes a problem. 

Because then you run again into the collect() code where you try to mark a 
memory allocation that hasn't been fully "constructed" (i.e. allocated and 
assigned to the gc memory management lists, but the ctor did not yet set up 
a valid vtbl pointer). 

If this is indeed the case we have to either make mark() non-virtual or make 
sure not to garbage collect as long as a constructor is run or solve this 
via some other way. 

> allocation is done before the respective ctor is run. And why didn't the
> following code in Collector::allocate() already help if there is a
> problem with the gc ?

This hack is ugly. IMHO it should be moved to the Imp constructor instead, I 
don't see why it makes a difference at this place (plus it breaks with 
virtual inheritance which we don't use AFAIK though). 

Am I really wrong that "new operator" + "operator new" is non-atomic ?


Dirk

[prev in list] [next in list] [prev in thread] [next in thread]