Re: [Oorexx-devel] Problem with SysStemSort, but ...

2009-05-25 Thread Rony G. Flatscher
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

[Oorexx-devel] Another observation (Re: Problem with SysStemSort, but ...

2009-05-25 Thread Rony G. Flatscher
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

Re: [Oorexx-devel] Questions ad Halt() and Terminate(), as well as RexxSetHalt()

2009-05-25 Thread Rick McGuire
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

Re: [Oorexx-devel] Questions ad Halt() and Terminate(), as well as RexxSetHalt()

2009-05-25 Thread Rony G. Flatscher
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.K.:

Re: [Oorexx-devel] Another observation (Re: Problem with SysStemSort, but ...

2009-05-25 Thread Rony G. Flatscher
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

[Oorexx-devel] Question ad compiler output for debugging

2009-05-25 Thread Rony G. Flatscher
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

Re: [Oorexx-devel] Question ad compiler output for debugging

2009-05-25 Thread Rony G. Flatscher
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 build

Re: [Oorexx-devel] Question ad compiler output for debugging

2009-05-25 Thread Rick McGuire
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.

Re: [Oorexx-devel] Question ad compiler output for debugging

2009-05-25 Thread Jean-Louis Faucher
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 when

Re: [Oorexx-devel] Question ad compiler output for debugging

2009-05-25 Thread Rony G. Flatscher
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 application