In article <firstname.lastname@example.org>,
Igor Kovalenko <email@example.com> wrote:
“Andrew Thomas” <> Andrew@cogent.ca> > wrote in message
news:> Voyager.010504115524.733220A@andrewhome.cogent.ca> …
Previously, Markus Loffler wrote in qdn.public.qnxrtp.photon:
Sorry don’t answer your question… but what is malloc_g?
It’s a replacement library for malloc() and free() that does some
bounds checking and memory corruption checking. All you should have
to do is use -lmalloc_g in the link line and you get a certain amount
of memory checking done for you (at a CPU penalty).
I believe it checks more than that. All memxxx() and strxxx() I think.
There is doc in ‘technotes’ section (Heap Analisys)
You’re right, Igor. The best indication of what checks it performs is
to read the tech note. Basically, any time you malloc or free, a number
of checks will be performed against the affected block. This may include
guard checking for overruns, as well as a bunch of consistency checks
on the block header – checksum, etc – to catch underruns – in addition
to basic validation, like duplicate free requests. The mem* and str*
functions are covered with versions that check if the parameter is
a valid heap block, then ensures that the range of the parameters is
within the bounds of the block.
The library can also trace the heap to determine if there are memory
As far as Andrew’s concern goes, we’ll have to see if the Photon library
group can do any tests to see what is occurring with PtFileSelector, or
perform more extensive testing against the library. I haven’t heard
of or seen this before.
Steve Furr email: firstname.lastname@example.org
QNX Software Systems, Ltd.