While continuing to rerun the ProgressDialog crash test case and peeking around
the stack traces, I
just hit a strange situation:
here just the top three entries):
> rexx.dll!ActivationFrame::ActivationFrame(Activity * a=0x00000000) Line
62 C++
rexx.dll!NativeActivationFrame::NativeActivationFrame(Activity *
a=0x00000000, NativeActivation * context=0x7e2736a8) Line 110 C++
rexx.dll!NativeActivation::callNativeRoutine(RoutineClass *
_routine=0x7dc99a38, NativeRoutine * _code=0x7dc99a18, RexxString *
functionName=0x7dc88378, RexxObject * * list=0x7d8ad100, unsigned int count=0,
ProtectedObject & resultObj={...}) Line 1339 C++
... cut ...
In callNativeRoutine(...) the statement that gets executed is:
NativeActivationFrame frame(activity, this);
"activity" and "this" have a value. However, when going to the next frame the
debugger points to:
inline NativeActivationFrame(Activity *a, NativeActivation *context) :
ActivationFrame(a), activation(context) { }
where "a" is NULL, which causes in the top frame the null pointer exception!
the "context" has the
value of the caller. As a result the statement in the top frame causes the
crash:
next = activity->activationFrames;
It is as if the argument "activity" pointing to a seemingly existing activity
in callNativeRoutine()
is not "arriving" in the inline ActivationFrame(), rather NULL arrives!
There are four rexx.dll threads:
*
Not Flagged 8704 0 Worker Thread
rexx.dll!TimeSliceControl () rexx.dll!TimeSliceControl
Above Normal
*
Not Flagged 7912 0 Worker Thread
msvcr100.dll!_threadstartex rexx.dll!waitHandle
Normal
*
Not Flagged > 8396 0 Worker Thread
rexx.dll!dispatch_activity_function ()
rexx.dll!ActivationFrame::ActivationFrame Normal
*
Not Flagged 7024 0 Worker Thread
rexx.dll!dispatch_activity_function () rexx.dll!waitHandle
Normal
---
Not sure, whether this is really helpful. Nevertheless I will keep the debug
window open in case
further information should be taken from the Visual Studio debugger. (Will have
to leave in a few
minutes, but thought I report this observation, in case it helps shed light.)
---rony
P.S.: Also, I have test-debug output with the hex values for each Rexx
interpreter instance and Rexx
thread context plus the numbers for the thread ids which match the debugger
values.
In addition, I created a version of it that has symbolic names RI-1 (for Rexx
interpreter # 1, the
primodal interpreter), RTC-2 (Rexx thread context 2, the second one created)
and TID-1 (the first
created thread). Actually, I wrote a program to rewrite the log outputs to make
them easier to read
and to understand, together with cross-references in which TID which RIs and
RTCs got used and the
like. (It would be great if ooRexx would be able to name these resources, i.e.
RII, TID and RTC, and
to retrieve those symbolic names at runtime as it really helps a *lot* when
looking through the log
output.)
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
