On Sat, Jul 30, 2016 at 5:11 PM, Erich Steinböck <[email protected] > wrote:
> If I have a reliable failing test case >> > Unfortunately I don't have a reliable failing test case. For me it happens > when playing with "testOOrexx" args. In this case I used "testOORexx -S -s > -X native_API -x CHAROUT TIME Alarm Message WindowsEventLog SpecialFolders". > It happens rarely, but it's by far not a one-off error. I believe it > happens more often with a release build, so I was "happy" to experience the > failure with a debug build where I could start the debugger upon failure. > > the bad object reference is the markObject used for the method call. I >> would set a break point in newObject() and catch that object being created >> and use the call stack to figure out the context of the creation >> > I kept the debugger open - is there anything I could provide in addition, > so we can figure out what's happening? > MemoryObject::newObject is being called for a type 36 object with a size > 133120. > That call is not of any interest. This is just the allocation that is triggering the current GC cycle. The problem will have already occurred on the previous GC cycle and occurs where there is a window where a GC cycle occurs in the window between an object getting created and the reference to that object getting anchored sometimes you can figure out where to look by looking at the call stack, but that's pretty rare. And since you are just running tests that are multi-threaded, they are probably not going to be reliably reproducible either because the GC window will move around. I can't think of anything in particular that I suggest you look at. Rick > > > Erich > > On Sat, Jul 30, 2016 at 7:41 PM, Rick McGuire <[email protected]> > wrote: > >> Usually you see this exception when an object gets garbage collected >> between the time it is allocated and it's reference is added to the >> traceable object mark set. This usually results in an object having a >> reference to another object that now points to the middle of another object >> because the storage is reclaimed. Usually this means there is a place where >> ProtectedObject is needed to anchor an object >> >> If I have a reliable failing test case, the bad object reference is the >> markObject used for the method call. I would set a break point in >> newObject() and catch that object being created and use the call stack to >> figure out the context of the creation and I'm usually able to figure out >> what additional ProtectedObject additions are needed. >> >> Rick. >> > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > >
------------------------------------------------------------------------------
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
