#738 3800 RXAPI unusual termination

[Mark Harsen]

I regret not having more information, but some rather large OOREXX applications of mine are starting to crash a lot with the same error message in a Windows dialogue box that says:

Runtime Error!

Program c:\Program Files\ooRexx\RXAPI.EXE

This application has requested the Runtime to terminate in an unusual way.
Please contact the application's support team for more information.

[OK]

Then it creates an error report and sends it off to Microsoft if I ok it. I can't reproduce this in smaller code and even the large server programs usually run for days before crashing with this error. Sometimes, however, I can reboot a server and the first transaction or so received will cause the error and the next reboot will serve thousands of transactions without any issues. Three servers running the code under 4.0 beta 4800 are experiencing these problems while the two 3.2 servers are running fine. Some of this code interfaces with EMTEC’s Zoc 6.11 - a rather nice TELNET/SSH program that can be driven by OOREXX.

I am willing to provide any debugging information, but I don't know how to proceed. All assistance is greatly appreciated!

Thank you, -Mark

[Mark Miesfeld]

Mark, it will probably be Rick to solve this, but here is some information you can get.

First, what OS are you on? That seems like a Vista message.

Second, when you get the pop up message box, this is from memory, there is a button or an option to view the report. Use that option. Then, you either get an edit box where you can copy and paste the whole message, or there is an option to copy the report. Do that and attach the report.

The report is probably no help, but we had one bug here where the report had a DrWatson log that showed exactly where the bug was. So, it wouldn't hurt to see what is in the report that is generated for your crash.

Oh, almost forgot, do you have rxapi installed as a system service or not?

Thanks

[Mark Harsen]

The OS is Windows XP professional in all cases with current patches. I don't install RXAPI as a service because my servers require an OOREXX startup script to execute on boot. Unfortunately, I found that the script tried to start before the RXAPI service was running and the script failed. Running without the service resolved this issue. Honestly, I haven't tried it under 4.0 to see if the same problem exists - guess I'll try it.

Next time I catch this failure, I'll update this with any reports I can get.

Thank you, -Mark

[Rick McGuire]

This may take a little bit to hunt down, but there's at least a memory leak in rxapi. The following simple program will show that the memory used by rxapi keeps growing:

do i = 1
push "Line" i
parse pull line
say line
end

[Rick McGuire]

I'm not 100% certain this is the fix for the problem, but there was a memory leak with the RexxPullQueue API that would potentially cause a crash after a large number of queue accesses. Since the programs from some of your earlier bug reports used the queue for RPC, this is likely the cause of the crash.

Committed revision 4840.

[Mark Harsen]

Fantastic! Yes, I use RXQUEUE extensively for multiprocessing communications and wind up putting a plethora of messages, some of which are fairly large, onto and off of multiple private queues simultaneously. I'll retest as soon as 4840 is available.

Thank you, -Mark

[Mark Miesfeld]

Mark,

We currently think this is fixed. I'm putting it back in pending.

When you add a comment, it automatically puts the item back in the open state. So, don't reply to this. <grin>

If your testing shows it is not fixed, then add a comment, set Resolution to None and Status to Open and we'll work on it further.

[Mark Harsen]

Unfortunately, this is still occurring under 4912. I tried to capture the contents of the report it was going to send to Microsoft, but when I did, the window flashed and closed. This time, however, I did trap the failed code, but I don't know if this will help. Any further attempts to use RXQUEUEs appears to fail - I'll try to catch more next time.

Thanks, -Mark

Error 48 Failure in system service
Error 48.1 Failure in system service: SYSTEM QUEUE
Traceback:
350 - Queue From Msg
429 - Call SendMsg .Master, Slave, 'ff'x "TERMINATE"
445 - Self~stop
911 - .Slaves~shutdown
218 - Msg = Self~CommandExec(Command, Cmds)

[Rick McGuire]

This is difficult to determine without an actual means of reproducing the problems, but the symptoms you report seem to suggest this is an unhandled exception from a C++ memory allocation failure. I've tightened up the error handling logic for memory failures and tried a number of low memory scenarios without getting any unexpected terminations.

[Mark Miesfeld]

The fix for this item was in the 4.0.0 release.