Kbase P8598: Memory Violations occurs with "omIDToarea called with 0 Obje
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
21/05/2004 |
|
Status: Verified
FACT(s) (Environment):
Progress 9.1C
FACT(s) (Environment):
Progress 9.1D
SYMPTOM(s):
omIdToArea called with 0 objectNumber
Client dies with Memory Violation (49)
Protrace file contains:
uttrace()
utcore()
drexit()
msgout()
msgdCB()
msgCB()
dsmMsgdCallBack()
omIdToArea()
dsmRecordUpdate()
nsadorm()
nsaloop()
doserve()
main()
_start()
CAUSE:
Bug #20010625-003
CAUSE:
Bug #20011106-008
CAUSE:
This is known issue that has been addressed in Progress 9.1C patches and the
commercial release of Progress 9.1D.
The error "omIDToarea called with 0 Objectnumber" occurs due to a timing issue of
nulling the pointers located in the lbi file. The pointers were nulled too late
in some cases causing the in-memory pointers to point to a place within the lbi
file that had already either already been committed or rejected, and thus to
garbage. In some instances the pointers were out-of-date and pointing at the
wrong image.
FIX:
Use the "-lbimod n" startup parameter to keep the dbimage up to date with the lbi
file.
The "-lbimod n" parameter was introduced in a patch to 9.1C and the release of
9.1D. The "lbimod n" parameter is set with the client startup parameters.
"-lbimod n"
n = 0 just the same as before
n = 1 fixes bug 20010625-003
n = 2 fixes both 20010625-003 and 20011106-008
Please note that each increased value is more restrictive then the previous
value.
THIS NEW OPTION SHOULD NOT BE USED UNLESS ONE OF THESE BUGS ARE A PROBLEM
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.
"-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.
If the issue still occurs after setting "-lbimod 1" use "-lbimod 2" in the CLIENT
CONNECT settings.
"-lbimod 2"
Forces Progress to reset a given buffer's in-memory lbi pointer to the latest
version of a change whenever we before-image an update, so it cannot end up
pointing at some earlier update. The "-lbimod 2" is a superset of "-lbimod 1"
and thus includes all of the "-lbimod 1" described above.