|
TURRIS::DECC is the home of the C RTL folks, and TURRIS::DECC_BUGS
is were various bugs are reported and discussed.
See the Internet patch area for any available RTL patches, and for
the associated documentation for the patches. (There are patches for
various DECC$SHR problems available for various OpenVMS versions...)
Given the 64Kbyte size, I'd guess you've encountered a bug (feature?)
of the DECC$SHR RTL.
I'd use an application-specific memory subsystem, based on calling
the LIB$ services directly. (This can allow you to customize the
memory handling, too -- the generic malloc/free routines are just
that, generic...)
|
| Is it possible to build a macro for calloc such as:
#define calloc(x,y) memset(malloc(x*y),(x*y))
and see if this exhibits the same behavior? I looked at the code for
calloc (which by the way is in LIBRTL, not the DEC C RTL) and it has
not changed between V6.2 and V7.1. I would think that if calloc did
have a problem, someone would have discovered it.
Typically these problems are caused by a memory corrupter in the users
application. Writing beyond the bounds of allocated memory may write
into the header part of adjacent modules causing the malloc routines to
go off the deep end.
If this is an internal application, I would recommend using something
like FAKE_VM or the heap analyzer.
Duane
|
|
As Duane indicates, these are usually application errors -- I prefer to
create application-specific memory allocation and deallocation routines,
as these provide a location where I can add application-specific memory
management features (appropriately-sized look-aside lists, etc), and
where I can add debugging code to catch any application errors that
might corrupt pool. (The routines I use often add a quadword at the
front and at the back of the actual memory allocation, fill the quads
with bit-patterns that can be checked at deallocation, and pass the
memory -- hiding the extra sixteen bytes -- back to the caller.)
Out of curiousity, look at the data structures in the pool around the
ACCVIO -- see what they are, and see if something in one of them has
overrun or underrun the allocated area and clobbered the pointers.
Also look carefully at the ACCVIO, as the contents of the ACCVIO signal
can sometimes contain data -- strings, etc, -- in the PC or virtual
address that can point to the corruption. (0x020202020 is a classic
ACCVIO footprint: ASCII spaces.)
|