Re: [Oorexx-devel] Update with further information ... (Re: Anyone with a more uptodate debugger? (Re: Segmentation faults in environmentEntries.testGroup
On 05.04.2024 16:04, Rick McGuire wrote:
The symptoms suggest a garbage collection problem during the copying of the behaviour object
during the setmethod calls. That probably requires a few protected objects to be added. However,
this is seriously using a sledge hammer to implement something that can be done much more simply.
Because all of the things that need to be done during a setmethod call, this is a very expensive
operation and should not typically be used for something that might be done repeatedly,
particularly on a object that is part of the saved image, which adds yet another layer of
complication to the garbage collection. Here is a much simpler and lower cost way to do the same
thing using the RUN() method to invoke the alternate formatter.
Rick, thank you very much for this workaround, it indeed makes the test suite run in full again
without causing a crash! Will commit the changes to trunk shortly.
---rony
P.S.: As setMethod/unsetMethod are documented they will get used in the wild such that we should
attempt to remove the root cause eventually.
On Fri, Apr 5, 2024 at 8:26 AM Rony G. Flatscher
wrote:
Thankfully Jean Louis was able to reproduce the crash and was able to trace
and to analyze the
problem further:
I can reproduce the crash under Windows ARM, same call stack as you.
The data breakpoint triggers 2 times, but it's a normal situation.
It's because of
.TraceObject~setMakeString(.resources~myMakeString)
.TraceObject~unsetMakeString -- reset (uses default implementation)
In both cases, a copy of the behaviour is assigned for this = RexxClass
"TraceObject"
>rexx.dll!RexxObject::defineInstanceMethod(RexxString * msgname,
MethodClass * methobj,
RexxClass * scope) Line 2310C++
{
...
// copy primitive behaviour object and define the method, a
copy is made to
// ensure that we don't update the behaviour of any other
object, since they
// may have been sharing the mvd.
setField(behaviour, (RexxBehaviour *)behaviour->copy());
...
}
>rexx.dll!RexxObject::deleteInstanceMethod(RexxString * msgname) Line
2335C++
{
...
// copy primitive behaviour object and define the method, a
copy is made to
// ensure that we don't update the behaviour of any other
object, since they
// may have been sharing the mvd.
setField(behaviour, (RexxBehaviour *)behaviour->copy());
...
}
I still don't know the root cause of the crash.
I protected buffer in RexxActivation::traceSourceString but the crash
still occurs.
After the crash, I noticed that the attribute owningClass of the
behaviour is NULL, which
is not normal.
I put a data breakpoint on owningClass but it doesnt trigger.
But good news:
If I put in comment the setMakeString & unsetMakeString, no more crash
(well… I tested only once, maybe I was lucky)
/[rgf: indeed, commenting out the setMakeString and unsetMakeString tests in
TRACE_TraceObject.testGroup makes the test suite pass without a crash
repeatedly]/
So there is maybe something to investigate around the impacts of this
assignement of
behaviour->copy()
... cut ...
Any idea what the problem might be and how to fix it?
---rony
P.S.: Thinking of notable things in this context:
* setMethod/unsetMethod in this case gets applied to a class object
* TraceObject subclasses StringTable which in native code subclasses
StringHashCollection
On 04.04.2024 19:04, Rony G. Flatscher wrote:
Am using an almost ten year old version of MVS (Microsfot Visual Studio),
which was bought
(but due to lack of money has not been updated by buying an update, newer
version).
It seems that I am not able to define a data break point with it for the
TraceObject
RexxClass object successfully. MVS in the breakpoint window seems to not be
able to allow for
setting a data breakpoint at
"RexxClass->RexxObject->RexxInternalObject->behaviour->methodDictionary" to
learn from where
in the ooRexx runtime this area gets overwritten.
Therefore, if anyone has newer debugging means and is able to recreate the
crash, then
requesting help to debug this strange situation (please see the call stack
below, the top
record is not always shown, the crash indicates that
behaviour->methodDictionary is NULL, yet
the class object got successfully used many times before in the test suite)!
Again, if the crash occurs then only after running the test suite with
"rexx testOORexx.rex
-s -U" from "test/trunk" in
"test\trunk\ooRexx\base\runtime.
Re: [Oorexx-devel] Update with further information ... (Re: Anyone with a more uptodate debugger? (Re: Segmentation faults in environmentEntries.testGroup
The symptoms suggest a garbage collection problem during the copying of the
behaviour object during the setmethod calls. That probably requires a few
protected objects to be added. However, this is seriously using a sledge
hammer to implement something that can be done much more simply. Because
all of the things that need to be done during a setmethod call, this is a
very expensive operation and should not typically be used for something
that might be done repeatedly, particularly on a object that is part of the
saved image, which adds yet another layer of complication to the garbage
collection. Here is a much simpler and lower cost way to do the same thing
using the RUN() method to invoke the alternate formatter.
Rick
On Fri, Apr 5, 2024 at 8:26 AM Rony G. Flatscher
wrote:
> Thankfully Jean Louis was able to reproduce the crash and was able to
> trace and to analyze the problem further:
>
> I can reproduce the crash under Windows ARM, same call stack as you.
>
> The data breakpoint triggers 2 times, but it's a normal situation.
> It's because of
> .TraceObject~setMakeString(.resources~myMakeString)
> .TraceObject~unsetMakeString -- reset (uses default implementation)
> In both cases, a copy of the behaviour is assigned for this = RexxClass
> "TraceObject"
>
>
> > rexx.dll!RexxObject::defineInstanceMethod(RexxString * msgname,
> MethodClass * methobj, RexxClass * scope) Line 2310 C++
> {
> ...
> // copy primitive behaviour object and define the method, a
> copy is made to
> // ensure that we don't update the behaviour of any other
> object, since they
> // may have been sharing the mvd.
> setField(behaviour, (RexxBehaviour *)behaviour->copy());
> ...
> }
>
>
> > rexx.dll!RexxObject::deleteInstanceMethod(RexxString * msgname) Line
> 2335 C++
> {
> ...
> // copy primitive behaviour object and define the method, a
> copy is made to
> // ensure that we don't update the behaviour of any other
> object, since they
> // may have been sharing the mvd.
> setField(behaviour, (RexxBehaviour *)behaviour->copy());
> ...
> }
>
>
> I still don't know the root cause of the crash.
> I protected buffer in RexxActivation::traceSourceString but the crash
> still occurs.
>
> After the crash, I noticed that the attribute owningClass of the behaviour
> is NULL, which is not normal.
> I put a data breakpoint on owningClass but it doesnt trigger.
>
> But good news:
> If I put in comment the setMakeString & unsetMakeString, no more crash
> (well… I tested only once, maybe I was lucky)
>
> *[rgf: indeed, commenting out the setMakeString and unsetMakeString tests
> in TRACE_TraceObject.testGroup makes the test suite pass without a crash
> repeatedly]*
>
> So there is maybe something to investigate around the impacts of this
> assignement of behaviour->copy()
> ... cut ...
>
> Any idea what the problem might be and how to fix it?
>
> ---rony
>
> P.S.: Thinking of notable things in this context:
>
>- setMethod/unsetMethod in this case gets applied to a class object
>- TraceObject subclasses StringTable which in native code subclasses
>StringHashCollection
>
>
> On 04.04.2024 19:04, Rony G. Flatscher wrote:
>
> Am using an almost ten year old version of MVS (Microsfot Visual Studio),
> which was bought (but due to lack of money has not been updated by buying
> an update, newer version).
>
> It seems that I am not able to define a data break point with it for the
> TraceObject RexxClass object successfully. MVS in the breakpoint window
> seems to not be able to allow for setting a data breakpoint at
> "RexxClass->RexxObject->RexxInternalObject->behaviour->methodDictionary" to
> learn from where in the ooRexx runtime this area gets overwritten.
>
> Therefore, if anyone has newer debugging means and is able to recreate the
> crash, then requesting help to debug this strange situation (please see the
> call stack below, the top record is not always shown, the crash indicates
> that behaviour->methodDictionary is NULL, yet the class object got
> successfully used many times before in the test suite)!
>
> Again, if the crash occurs then only after running the test suite with
> "rexx testOORexx.rex -s -U" from "test/trunk" in
> "test\trunk\ooRexx\base\runtime.objects\environmentEntries.testGroup".
> Running that test group standalone does not crash here.
>
> Any help highly appreciated!
>
> ---rony
>
>
>
> On 03.04.2024 17:29, Rony G. Flatscher wrote:
>
> On 03.04.2024 16:25, ooRexx wrote:
>
> It seems we currently have ALL platforms failing this test, can the person
> (Rony?) who committed lately check if there was a side-effect of the
> changes and/or amend the test to the new behaviour.
>
> Executing .../ooRexx/base/runtime.objects/environmentEntries.testGroup
> /tmp/jenkins3639803152023253797.sh: line 15: 26971 Segmentation fault
> (core dump
[Oorexx-devel] Update with further information ... (Re: Anyone with a more uptodate debugger? (Re: Segmentation faults in environmentEntries.testGroup
Thankfully Jean Louis was able to reproduce the crash and was able to trace and to analyze the
problem further:
I can reproduce the crash under Windows ARM, same call stack as you.
The data breakpoint triggers 2 times, but it's a normal situation.
It's because of
.TraceObject~setMakeString(.resources~myMakeString)
.TraceObject~unsetMakeString -- reset (uses default implementation)
In both cases, a copy of the behaviour is assigned for this = RexxClass
"TraceObject"
>rexx.dll!RexxObject::defineInstanceMethod(RexxString * msgname,
MethodClass * methobj,
RexxClass * scope) Line 2310C++
{
...
// copy primitive behaviour object and define the method, a
copy is made to
// ensure that we don't update the behaviour of any other
object, since they
// may have been sharing the mvd.
setField(behaviour, (RexxBehaviour *)behaviour->copy());
...
}
>rexx.dll!RexxObject::deleteInstanceMethod(RexxString * msgname) Line
2335C++
{
...
// copy primitive behaviour object and define the method, a
copy is made to
// ensure that we don't update the behaviour of any other
object, since they
// may have been sharing the mvd.
setField(behaviour, (RexxBehaviour *)behaviour->copy());
...
}
I still don't know the root cause of the crash.
I protected buffer in RexxActivation::traceSourceString but the crash still
occurs.
After the crash, I noticed that the attribute owningClass of the behaviour
is NULL, which is not
normal.
I put a data breakpoint on owningClass but it doesnt trigger.
But good news:
If I put in comment the setMakeString & unsetMakeString, no more crash
(well… I tested only once, maybe I was lucky)
/[rgf: indeed, commenting out the setMakeString and unsetMakeString tests in
TRACE_TraceObject.testGroup makes the test suite pass without a crash repeatedly]/
So there is maybe something to investigate around the impacts of this
assignement of
behaviour->copy()
... cut ...
Any idea what the problem might be and how to fix it?
---rony
P.S.: Thinking of notable things in this context:
* setMethod/unsetMethod in this case gets applied to a class object
* TraceObject subclasses StringTable which in native code subclasses
StringHashCollection
On 04.04.2024 19:04, Rony G. Flatscher wrote:
Am using an almost ten year old version of MVS (Microsfot Visual Studio), which was bought (but
due to lack of money has not been updated by buying an update, newer version).
It seems that I am not able to define a data break point with it for the TraceObject RexxClass
object successfully. MVS in the breakpoint window seems to not be able to allow for setting a data
breakpoint at "RexxClass->RexxObject->RexxInternalObject->behaviour->methodDictionary" to learn
from where in the ooRexx runtime this area gets overwritten.
Therefore, if anyone has newer debugging means and is able to recreate the crash, then requesting
help to debug this strange situation (please see the call stack below, the top record is not
always shown, the crash indicates that behaviour->methodDictionary is NULL, yet the class object
got successfully used many times before in the test suite)!
Again, if the crash occurs then only after running the test suite with "rexx testOORexx.rex -s -U"
from "test/trunk" in "test\trunk\ooRexx\base\runtime.objects\environmentEntries.testGroup".
Running that test group standalone does not crash here.
Any help highly appreciated!
---rony
On 03.04.2024 17:29, Rony G. Flatscher wrote:
On 03.04.2024 16:25, ooRexx wrote:
It seems we currently have ALL platforms failing this test, can the person (Rony?) who committed
lately check if there was a side-effect of the changes and/or amend the test to the new behaviour.
Executing .../ooRexx/base/runtime.objects/environmentEntries.testGroup
/tmp/jenkins3639803152023253797.sh: line 15: 26971 Segmentation fault (core dumped) rexx
testOORexx.rex -s -U
Build step 'Execute shell' marked build as failure
Finished: FAILURE
Could get that crash on my debug version on Windows 10, here the call stack:
() Unknown
>rexx.dll!MethodDictionary::getMethod(RexxString *
methodName=0x01bcdda2bdd0) Line 69C++
rexx.dll!RexxBehaviour::methodLookup(RexxString *
messageName=0x01bcdda2bdd0) Line 443 C++
rexx.dll!RexxObject::messageSend(RexxString * msgname=0x01bcdda2bdd0,
RexxObject * * arguments=0x, unsigned __int64 count=0,
ProtectedObject & result={...}) Line 871 C++
rexx.dll!CreateTraceObject(Activity * activity=0x01bcddc64eb0,
RexxActivation * activation=0x01bcf6a669a0, RexxString *
traceline=0x01bcf6a3d2d0) Line 3097 C++
r
Re: [Oorexx-devel] Anyone with a more uptodate debugger? (Re: Segmentation faults in environmentEntries.testGroup
Hi P.O.,
On 04.04.2024 22:34, P.O. Jonsson wrote:
We are using the Community Edition of Visual Studio for all Windows platforms since it is free of
charge; is there anything missing in that edition that you need?
We have at least 2017, 2019 and 2022 editions installers saved, I will send you a private message
just now.
thank you very much!
Best regards
---rony
Am 04.04.2024 um 19:04 schrieb Rony G. Flatscher :
Am using an almost ten year old version of MVS (Microsfot Visual Studio), which was bought (but
due to lack of money has not been updated by buying an update, newer version).
It seems that I am not able to define a data break point with it for the TraceObject RexxClass
object successfully. MVS in the breakpoint window seems to not be able to allow for setting a
data breakpoint at "RexxClass->RexxObject->RexxInternalObject->behaviour->methodDictionary" to
learn from where in the ooRexx runtime this area gets overwritten.
Therefore, if anyone has newer debugging means and is able to recreate the crash, then requesting
help to debug this strange situation (please see the call stack below, the top record is not
always shown, the crash indicates that behaviour->methodDictionary is NULL, yet the class object
got successfully used many times before in the test suite)!
Again, if the crash occurs then only after running the test suite with "rexx testOORexx.rex -s
-U" from "test/trunk" in "test\trunk\ooRexx\base\runtime.objects\environmentEntries.testGroup".
Running that test group standalone does not crash here.
Any help highly appreciated!
---rony
On 03.04.2024 17:29, Rony G. Flatscher wrote:
On 03.04.2024 16:25, ooRexx wrote:
It seems we currently have ALL platforms failing this test, can the person (Rony?) who
committed lately check if there was a side-effect of the changes and/or amend the test to the
new behaviour.
Executing .../ooRexx/base/runtime.objects/environmentEntries.testGroup
/tmp/jenkins3639803152023253797.sh: line 15: 26971 Segmentation fault (core dumped) rexx
testOORexx.rex -s -U
Build step 'Execute shell' marked build as failure
Finished: FAILURE
Could get that crash on my debug version on Windows 10, here the call stack:
() Unknown
>rexx.dll!MethodDictionary::getMethod(RexxString *
methodName=0x01bcdda2bdd0) Line 69C++
rexx.dll!RexxBehaviour::methodLookup(RexxString *
messageName=0x01bcdda2bdd0) Line 443 C++
rexx.dll!RexxObject::messageSend(RexxString * msgname=0x01bcdda2bdd0,
RexxObject * * arguments=0x, unsigned __int64 count=0,
ProtectedObject & result={...}) Line 871 C++
rexx.dll!CreateTraceObject(Activity * activity=0x01bcddc64eb0,
RexxActivation * activation=0x01bcf6a669a0, RexxString *
traceline=0x01bcf6a3d2d0) Line 3097 C++
rexx.dll!Activity::traceOutput(RexxActivation *
activation=0x01bcf6a669a0, RexxString * line=0x01bcf6a3d2d0) Line 3141
C++
rexx.dll!RexxActivation::traceSourceString() Line 3912 C++
rexx.dll!RexxActivation::traceClause(RexxInstruction *
clause=0x01bce65e36e0, RexxActivation::TracePrefix
prefix=TRACE_PREFIX_CLAUSE) Line 4200 C++
rexx.dll!RexxActivation::traceInstruction(RexxInstruction *
v=0x01bce65e36e0) Line 370 C++
rexx.dll!RexxInstructionAssignment::execute(RexxActivation *
context=0x01bcf6a669a0, ExpressionStack * stack=0x01bcf6a66b08) Line
118 C++
rexx.dll!RexxActivation::run(RexxObject * _receiver=0x01bcf0100e50,
RexxString * name=0x01bce65e2600, RexxObject * * _arglist=0x01bcf6a668a0,
unsigned __int64 _argcount=0, RexxInstruction * start=0x,
ProtectedObject & resultObj={...}) Line 626 C++
rexx.dll!RexxCode::run(Activity * activity=0x01bcddc64eb0, MethodClass
* method=0x01bce65e4db0, RexxObject * receiver=0x01bcf0100e50, RexxString *
msgname=0x01bce65e2600, RexxObject * * argPtr=0x01bcf6a668a0, unsigned
__int64 argcount=0, ProtectedObject & result={...}) Line 211 C++
rexx.dll!MethodClass::run(Activity * activity=0x01bcddc64eb0,
RexxObject * receiver=0x01bcf0100e50, RexxString * msgname=0x01bce65e2600,
RexxObject * * argPtr=0x01bcf6a668a0, unsigned __int64 count=0, ProtectedObject
& result={...}) Line 172 C++
rexx.dll!RexxObject::messageSend(RexxString * msgname=0x01bce65e2600,
RexxObject * * arguments=0x01bcf6a668a0, unsigned __int64 count=0,
ProtectedObject & result={...}) Line 901 C++
rexx.dll!MessageClass::dispatch() Line 445 C++
rexx.dll!MessageClass::send() Line 413 C++
rexx.dll!MessageClass::sendRexx(RexxObject * *
arguments=0x01bcde86a5b0, unsigned __int64 argCount=0) Line 329 C++
rexx.dll!CPPCode::run(Activity * activity=0x01bcddc64eb0, MethodClass *
method=0x01bcddb55b60, RexxObject * receiver=0x01bcf6a66920,
