G
Garry Hall
Guest
The AVM does not currently allow you to catch access violations/segfaults. The AVM doesn’t handle access violations other than to dump diagnostics (protrace) and exit. For most of the AVM, we try to address the underlying causes of access violations, with the intent that users should never be able to cause a crash using pure ABL. Once you enter DLL-land, the AVM doesn’t protect you from yourself. Protecting this has been mentioned in the past, but is not yet implemented. There are challenges to it: for example, within a DLL, there is no way to prevent the DLL from modifying any writable address in the address space. So your DLL could (inadvertently) write to an address that won’t cause a problem whilst in the DLL, but could cause a crash much later. Is it possible to use an alternative API that will return an error code and required size if the target memptr is not long enough? From: MABeatty1978 [mailto:bounce-MABeatty1978@community.progress.com] Sent: Thursday, July 10, 2014 1:45 PM To: TU.OE.Development@community.progress.com Subject: [Technical Users - OE Development] Handling System Error: Memory Violation Handling System Error: Memory Violation Thread created by MABeatty1978 Is there a way to catch a memory violation and prevent it from killing Progress? I've got a Progress function that calls a C++ API. The function sends a request message and the API returns a reply message in a mqmptr.. Problem is the size of the reply message can vary from 0 byes, to 100MB. What I was hoping to do was to set the memptr size to a reasonable size that would catch MOST of the messages, in the ball park of 20000b. Then, if the memptr doesn't have enough memory to hold the reply, bump the memptr size up and try again. Unfortunately, it just seems that Progress dies on a Memory Violation. I've been tying to get it in a CATCH, which it does catch, but I can't figure out how to handle the error as Progress dies regardless of the CATCH. Thank you. Stop receiving emails on this subject. Flag this post as spam/abuse.
Continue reading...
Continue reading...