| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1454.1 | More info | CRAYON::GENT | Revolutionize yourself | Thu Sep 21 1995 16:09 | 6 |
| 1454.2 | | CSC32::D_DERAMO | Dan D'Eramo, Customer Support Center | Thu Sep 21 1995 17:06 | 9 |
| 1454.3 | Thank you (sigh) | CRAYON::GENT | Revolutionize yourself | Fri Sep 22 1995 09:42 | 8 |
| 1454.4 | Thank you. Dan and FAKE_VM solved my problem. | CRAYON::GENT | Revolutionize yourself | Fri Sep 22 1995 14:34 | 9 |
| 1454.5 | VAX/VMS V5.5-2, DECC V5.0-003; FAKE_VM available? | LASSIE::BISHOV | | Wed May 21 1997 15:39 | 24 |
| Am having a problem which may be similar to the one Andrew outlined in
the base note for this stream. Dump for error includes the following
lines at the top, with the line in MAKE_LIB being at a malloc call:
SHARE$LIBRTL 00000000 00064522
SHARE$DECC$SHR 00000000 00034C47
MAKE_LIB MAKEVARBINDWITHVALUE 0000004A 0001435E
.
.
.
For similar problem at different program locations, the top two pc
values are the same; all lines in application code come from malloc
calls.
Note .3 refers to FAKE_VM as a way of locating locations of overwritten
memory. Is that, or a similar method, available? (This is code I've
inherited, do not yet know all the details, but can reproduce the
getting the ROPRAND error when forcing many small mallocs. Still
checking for memory leak.)
Thanks,
Sheldon
|
| 1454.6 | Heap Analyzer, If You Can Use V6.1 or Later... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Wed May 21 1997 16:59 | 18 |
|
FAKE_VM has been available for a while, and there are likely versions
for OpenVMS VAX V5.5-2. The conference is located at CLT::FAKE_VM.
Another option would be a test bed running a rather more recent version
of OpenVMS VAX (such as V6.1), and using the Heap Analyzer present in
the OpenVMS Debugger.
I've typically used "wrappers" around lib$get_vm calls and centralized
all memory management into a few (or one) source modules -- with names
and calling interfaces similar to malloc() -- and have then been able
to place quadwords at the front and the back of the allocated area,
hidden from the caller. I could then use these quadwords to detect
all manner of data under- or over-runs, and could use the rest of the
lib$vm calls to check the status or -- my favorite technique -- flush
whole pools of temporary memory in a single call. (This is a variantion
on what FAKE_VM does.)
|
| 1454.7 | Thanks, will take a look | UCXAXP::BISHOV | | Thu May 22 1997 09:04 | 7 |
| Thanks for the suggestions, Steve. The first two options look like the
best to try short term. The last may be long term possibility, since
it sounds like the most sound from an engineering point of view; right
now since the problem is in ported code I've just taken over, am aiming
to make as few changes as possible.
Sheldon
|