Kbase P4133: omIDToarea called with 0 Objectnumber error occurs in Database logfile.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
22/01/2010 |
|
Status: Verified
SYMPTOM(s):
Client dies with Memory Violation (49)
SYSTEM ERROR: Memory violation. (49)
omIDToarea called with 0 Objectnumber
Stack trace from _progres reads:
dsmMsgdCallBack
omIdToArea <<
dsmRecordUpdate
nsadorm
FACT(s) (Environment):
Progress 9.1C
Progress 9.1D
Progress 9.1E
All Supported Operating Systems
CAUSE:
The error has been found to be linked to a "timing" problem rather than a specific scenario. ie: with uncommon conditions that depend on the exact sequence in which the 4GL program has done/undone/redone[sub]transactions.
FIX:
This is issue has been addressed in Progress 9.1C patches and the commercial release of Progress 9.1D.
To resolve the problem perform one of the following:
1. Upgrade to 9.1C last patch or Progress 9.1D or later.
2. Then use the "-lbimod n" startup parameter as described below
The "-lbimod n" client startup parameter was introduced in a patch to 9.1C and the release of 9.1D which changes the way the "local before image" pointer is managed.
"-lbimod n"
n = 0 the behaviour as previously
n = 1 fixes the timing issue by keeping the dbimage up to date with the lbi file.
Please note that the increased value is more restrictive then the previous value (see below).
The "-lbimod" startup parameter does not work without first applying the above mentioned versions of Progress or later.
THIS NEW OPTION SHOULD NOT BE USED BY DEFAULT, BUT ONLY IF THE BEHAVIOUR CONTINUES AFTER INSTALLATION OF THE RELEVANT PATCH.
Explanation of the "-lbimod" parameter:
When a record is written to the lbi file, a pointer is written to the record buffer that points to the record entry within the lbi file. When the same record is update multiple times, instead of creating multiple copies of the same record within the lbi file a pointer is written lbi file instead that refers to the earlier image of the record within the lbi file, instead of writing the entire record again.
For example, if a record has already been written once during a current accept/reject unit (DO, REPEAT etc. block), then an lbi note referring to the earlier image is used, instead of the an lib note with the entire record.
After applying the relevant patch, include "-lbimod 1" in the CLIENT CONNECTION parameters. Please note, this parameter does not work without first applying the above mentioned patches. And memory should be cleared on this system first.
"-lbimod 1"
Ensures that Progress will go back over all the in-memory buffers and null out any pointers that point beyond the new endpoint of the lbi file. This occurs whenever the lbi endpoint is reset to some position earlier than what it was - e.g. after a commit or reject, to prevent any possible pointing into garbage.
Do not use -lbimod 2 in any situation. Please check the solution P98325 for more information.