Note that you really have very limited ability to do anything in a
package unloader. At this point, everything is shutting down. All of
the instances have been cleaned up already and this is one of the very
last steps in the process of cleaning thiings up. I doesn't surprise
me that you might be
Rick McGuire wrote:
> This is exactly the last scenario I described to you yesterday and you
> adamantly declared that RexxCreateInterpreter was not getting called.
> There is an association between a thread and the "top-most" thread
> context that is created on that thread. Once you call
> RexxC
This is exactly the last scenario I described to you yesterday and you
adamantly declared that RexxCreateInterpreter was not getting called.
There is an association between a thread and the "top-most" thread
context that is created on that thread. Once you call
RexxCreateInterpreter on a given thr
Rick McGuire wrote:
> I just thought of one more thing that could cause the error you're
> seeing. If you do an AttachThread() at some point and neglect to do a
> corresponding DetachThread() before returning to your caller, you'll
> end up with a corrupted activaation stack that will result in p
Rick McGuire wrote:
> Definitely not enough to determine the problem. This very much looks
> like there had to have been an memory overlay based on the location of
> the trap. The most likely explanation is a wild store by some other
> external routine, perhaps a problem in BSFRexx itself.
>
Rick McGuire wrote:
> I just thought of one more thing that could cause the error you're
> seeing. If you do an AttachThread() at some point and neglect to do a
> corresponding DetachThread() before returning to your caller, you'll
> end up with a corrupted activaation stack that will result in pr
Rony,
I just thought of one more thing that could cause the error you're
seeing. If you do an AttachThread() at some point and neglect to do a
corresponding DetachThread() before returning to your caller, you'll
end up with a corrupted activaation stack that will result in problems
with legacy ca
Definitely not enough to determine the problem. This very much looks
like there had to have been an memory overlay based on the location of
the trap. The most likely explanation is a wild store by some other
external routine, perhaps a problem in BSFRexx itself.
Rick
On Sun, May 24, 2009 at 7:0
Forgot the stack trace, here it goes:
> rexx.dll!RexxLocalVariables::get(unsigned int index=0) Line 119 + 0xa
bytesC++
rexx.dll!RexxActivation::getLocalStemVariable(RexxString *
name=0x7ef108d8, unsigned int index=0) Line 463 + 0x12 bytesC++
rexx.dll!RexxActiv
