Jean-Louis,
> Since you have
> EXCEPTION_ACCESS_VIOLATION (0xc005)
> you can try to select the "Access violation" in Debug / Exceptions,
> under "Win32 exceptions".
> See http://msdn.microsoft.com/en-us/library/d14azbfh.aspx
> It's written :
> The debugger can break execution of your applicatio
Jean-Louis,
thank you very much for this tip, sounds very promising!
Tried to apply it, and it works, except that in this particular use case
where Halt() is invoked the halt condition seems to prevail and when I
finally get to attach and break-all, I am already stuck at that "ret"
instruction, n
Rony,
Since you have
EXCEPTION_ACCESS_VIOLATION (0xc005)
you can try to select the "Access violation" in Debug / Exceptions, under
"Win32 exceptions".
See http://msdn.microsoft.com/en-us/library/d14azbfh.aspx
It's written :
The debugger can break execution of your application immediately whe
Rony,
Another tip :
add 'pause' in the rexx script of interest.
When paused, attach to the java process, break all, and you should see
usefull things.
>From here you can put breakpoints (or re-activate them because VS remembers
them).
About the debug symbols, if you see "Symbols loaded" in the ou
Just building a debug version of the install package is not enough.
You also need to place the symbols files in the same directory so the
debugger can find the symbols. Everything you've shown so far
suggests the symbol files are getting located.
Rick
On Mon, May 25, 2009 at 3:13 PM, Rony G. Fla
Rick McGuire wrote:
> Have you tried building a a debug vsrsion of ooRexx to run with? If
> you're running from an installed version, build the debug version and
> drop the new .exes and dlls in the install location, along with the
> .pdb files containing the debug symbols.
>
Yes, I always bui
Have you tried building a a debug vsrsion of ooRexx to run with? If
you're running from an installed version, build the debug version and
drop the new .exes and dlls in the install location, along with the
.pdb files containing the debug symbols.
Rick
On Mon, May 25, 2009 at 3:00 PM, Rony G. Fla
Jean-Louis,
> Instead of pressing Ctrl-C, maybe the "Attach to process" of MSVS2008
> could help ? At least, you should see if the symbols are loaded or
> not. And a "break all" should give access to the call stack.
thank you very much for this tip!
Just tried it, but in this use case a popup is s
Rony,
Instead of pressing Ctrl-C, maybe the "Attach to process" of MSVS2008 could
help ? At least, you should see if the symbols are loaded or not. And a
"break all" should give access to the call stack.
Jean-Louis
--
Reg
Currently, whenever I run into an exception under the control of Java,
the MSVS2008 Professional debugger does not get triggered, instead a
file hs*.log gets created with all sort of interesting information.
Eg. (this one is from pressing Ctl-c in a hanging ooRexx program, that
got started via Jav
Rick McGuire wrote:
> The other possibility is you've called RexxCreateInterpreter() on a
> thread that was already owned by Rexx. In that case, the
> RexxThreadContext returned with the instance pushes down the active
> one and can create the same symptoms if you return without destroying
> the
Rick McGuire wrote:
> Terminate() does not terminate threads, it terminates the interpreter
> instance. The termination call can only be made on the original
> thread that created the interpreter instance and will wait for any
> other threads to terminate before shutting down the instance.
>
O
The other possibility is you've called RexxCreateInterpreter() on a
thread that was already owned by Rexx. In that case, the
RexxThreadContext returned with the instance pushes down the active
one and can create the same symptoms if you return without destroying
the instance. In that situation, y
Terminate() does not terminate threads, it terminates the interpreter
instance. The termination call can only be made on the original
thread that created the interpreter instance and will wait for any
other threads to terminate before shutting down the instance.
Halt() can be issued from any thre
In the new APIs one is able to use the Rexx interpreter instance to
issue a Halt() and/or Terminate(), which will halt/terminate all Rexx
threads of that particular Rexx interpreter instance.
Question: is it possible that problems arise, if Halt() and Terminate()
are not issued from the thread tha
Rick,
when invoking that program via Java, then it works without a problem!
If invoked via Java then in the native layer an AttachThread() is
invoked, a Routine object is created and invoked with CallRoutine(),
followed by a matching DetachThread().
---rony
Rony G. Flatscher wrote:
> Rick McG
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
18 matches
Mail list logo
