Troubleshooting steps:Due to the vastly different circumstances that can lead to a Memory Violation, the following list can be used as a guide on ways to narrow down and potentially isolate or resolve the issue.
- Determine when the error occurs and if it occurs consistently. Is the error reproducible?
- If the task was previously running fine but now starts producing the error, what has changed since before the error started occurring?
- If a protrace file was generated, it may identify what programs were running at the time and what function the executable had in memory at the time of the error. Also, does the protrace file contain a consistent stack trace each time the error occurs?
- If the problem is reproducible it may be possible to narrow down the code by using additional logging capabilities available in later OpenEdge releases. For example, 4GLTracing. Please see the Notes section below for links to related Articles.
- If memory on the machine is cleared by rebooting, does SYSTEM ERROR 49 reappear?
- Is memory being exhausted during the time when the failing task is run?
If memory is being exhausted, try lowering the -e, -l, -s, -Bt, -c client startup parameters to reduce memory usage. If the database resides on the same machine, also try reducing database startup parameters such as –B.
If the process that caused the memory violation was using an unusually large amount of memory, there could be a memory leak within the process or the associated programs being run.
- The client stack may have been corrupted because it is too small and is being overwritten. Try increasing the ABL client –s parameter.
- Verify that the system has sufficient swap space. On UNIX/Linux, swap space should be configured for an amount twice the installed RAM. On Windows, the swap file can be configured to be a System Managed size and can grow as required.
- Check the hardware for errors.
Hardware logs on UNIX, Linux or Windows Event Viewer should be checked for errors, however hardware faults are not always detected or logged. If no errors are present in the logs, have the hardware provider run low level diagnostic checks for issues in components such as memory, CPU, Disk Controllers, Motherboard.
- R-code may be corrupt or incompatible with the Progress release being used. Recompile the application code that is being used against the version that's using it.
- Reinstall Progress to eliminate a corrupt installation.
- If multiple versions of Progress are installed, ensure that environment scripts are properly configured for the version intended, environment variables are pointing to the correct Progress version or libraries and on UNIX/Linux there are no Progress/OpenEdge scripts from multiple installs that were copied to /usr/bin
- Check whether there is data or index corruption within the database. Please see the Notes section below for links to related Articles.
- If the Progress installation is on UNIX/Linux and has recently been upgraded or there has been an increase in the number of databases or users, it may be required to re-tune the kernel to increase system resources such as file handles. Please refer to the Progress Installation and Configuration Guide for more details.
- Verify that the Progress/OpenEdge release being used is running on a supported operating system version as per the Product Availability Guide in the Notes section.
- If none of the above measures fix it, it might be a Progress bug.
For example there is a known issue with async unsafe signal handling on UNIX/Linux which result for example in SYSTEM ERROR 49 when a signal is sent at the wrong time. An upgrade to at least OpenEdge 11.6.3. For further information refer to the following Article and related links:
Narrow the issue down as much as possible and search the Progress knowledgebase using keywords that are more specific to the issue being encountered.
If the cause and/or solution cannot be determined, provide any steps to reproduce, relevant logs, code and protrace files to Progress Technical Support.
If on UNIX/Linux and a protrace file was not created but a core file was, you may be asked to convert the core file to a stacktrace using a system debugger and submit it to Technical Support for analysis. Do not provide the core file to Technical Support unless requested as often the conversion of the core file to stacktrace must be performed on the same machine using the same Progress version that generated it.
Tools for Diagnosing Memory and Access Violations
Protrace files
When an OpenEdge process crashes it attempts to write a protrace file to the working directory of the process that crashed. Depending upon the success or failure of the process' attempt to interface with the OS debugger a protrace file may or may not be generated.
The information provided in a protrace file is constantly improving. At the time of this writing, the protrace file contains the following information:
- The date and time of the crash (no timezone information)
- The exact OpenEdge version of the process that experienced the crash
- All of the parameters that were used to start the session
- .pf files are referenced, then expanded to list all contained parameters, terminated by (end .pf)
- Exception code (e.g. C0000005 ACCESS_VIOLATION)
- Fault address: Includes address and module name (e.g. _mprosrv, _progres.exe, prow.dll, etc)
- Program Registers
- Debugging dll - OS debugger
- Symbol Path - Where the debugger was told to search for PDB files (Program Database Files) - Windows only
- Call Stack
- ABL Stack Trace - for ABL processes
- SQL Stack
