>
> 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.

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

Reply via email to