Consultor Eletrônico

Status: Verified

GOAL:

SYSTEM ERROR: Memory violation. (49)

GOAL:

What is a System Error: Memory Violation (49)

GOAL:

Analyzing the causes of Memory Violation (49).

GOAL:

How to troubleshoot a memory violation (49).

FIX:

Possible causes of Memory Violation(49):

Memory Violation (error 49) (Access violation on Windows) means the program has attempted to read from or write to a memory location that is outside the process address space. This means some code somewhere is using an incorrect pointer. Most commonly it appears in the following instances:


uninitiate variable in C, C++
incorrect calculation of an address
reference past the end of an array in C, C++
pointer variable's contents have been smashed
some data structure has been smashed
stack has been smashed
rcode corrupted on disk somehow
4GL application passes bad parameters to a function in a dl
4GL application calling HLC code with bugs in it (usually not done on Windows)
code in a dll being called and code in it has a bug
ActiveX control has a bug
database is corrupted
bi log is corrupted
ai log is corrupted
Progress executable(s) or shared libaries corrupted
An installation replaced a dll with an incompatible version
we start processing events in the middle of an operation that is not supposed to be interrupted
executable has been corrupted on disk somehow
bad disk causes swap corruption (not common)
bad memory causes memory corruption (not common)
other hardware problems (not common)
Not enough memory on the machine
Not enough configured swap space on the machine
A Progress executable compiled under an incompatible operating system or operating system level
Newly upgraded Progress installation
Progress bug
If nothing has been corrupted, then a reproducible occurrence is likely to be a Progress bug. The specific cause is usually hard to determine because in most cases the access violation is a symptom that is a side-effect of the real problem, and it usually happens long after (in number of instructions executed) the code with the bug in it executed. Often the call stack in the protrace files helps. It allows us to figure out what part of our code was being executed, which can be helpful.

4GL code is NEVER supposed to produce an error 49 or a GPF. There are only a few scenarios where the 4GL programmer can be responsible:
- Improper use of MEMPTR variables, specifically when using the GET-POINTER-VALUE() and SET-POINTER-VALUE() functions
- Improper handling of calls into external libraries (dlls/shared libraries or COM objects)
Troubleshooting steps:
You must determine when the error occurs and if it occurs consistently. If you have been running fine but now you start receiving the error, think about what has changed since before the error started occurring.


In general, you can try the following:

Clear memory on your machine by rebooting the system and see if the error 49 reappears.
Reduce the -e, -l, -s, -B, -c startup parameters to save memory.

To see what these parameters are set to, use PROMON (Progress monitor) or check the script (.bat on DOS, .com on VMS) or Progress parameter file (Version 6) that you use to start the Progress session.
Specific corrective measures are as follows:




Check the amount of memory installed and the number of users on the system.

A rule of thumb for this relationship is 1 MB for the system and first user, then each additional MB serves 2 or 3 users.
An Error 49 may also indicate that the stack has been corrupted, because it is too small and is being overwritten.

Solution: increase -s might eliminate the error.



Increase swap space.

Swap. space should be configured for an amount twice the installed RAM. You can run the system utility that shows swapping/paging information to see what is happening (for example, S.A.R on UNIX or VMS monitor).



Check your hardware log to see if there are other errors.
Recompile the compiled (.r) code that you are running.

If this seems to cure the problem for a while, only to have it reappear, check the speed of the CPU versus the speed of the system memory.

Progress Technical Support has observed, on SCO OpenServer 5 with a dual CPU running at 150MHz and 12 ns external cache RAM, that the CPU is faster than memory can handle. The error disappeared when external cache was turned off.


Instructions with the AMI motherboard state that if the CPU is moved from 66MHz to 100MHz, change cache RAM from 15 ns to 12 ns. No information is available for the 150 MHz CPU.

Reinstall Progress.
Verify via the Technical Bulletin that you have at least the first known operating system level that supports the Progress version you are running.
Locate the bad record, delete, and recreate it.


Or, dump and reload that file. If you are not able to work with the entire file at once, you might have to dump around the bad record(s) and load the data back in pieces.

Receipt of Error (49) while in you are in single user mode can indicate .bi file corruption.

This could be caused by a hardware error. Check your system log files and run diagnostics if necessary.

Solution: Go to a backup or, if you have no available backup, force access with the -F option and then dump/load to regain database integrity.

NOTE: This latter option can result in the loss of any data that was written to the .bi file but not yet written to the .db file.


If the Error 49 is reproducible and none of the above measures fix it, it might be a Progress bug.


Narrow it down to code that is reproducible in the Progress demo database and submit it to Progress Technical Support.

If you have recently upgraded your Progress installation, you might need to return the kernel on UNIX operating systems to provide more memory space to Progress.

But, verify that the problem is related to the size of the new executable by obtaining a ProTrace and forward that to Progress Technical Support for analysis.

If you are on a UNIX machine, you might also be asked by a support representative to dump the core file to an ASCII file, using the system debugger and submit it to support for analysis.
.