Solutions to gmem.c ENABLE_MEM_CHECK crashes



On Tue, Oct 06, 1998 at 09:20:24PM -0700, Seth Burgess wrote:
> I've put the gtk guru on the notify list, so it will be considered :)
> Thanks for the patch - hopefully it'll get applied RSN

Having my glib compiled with MEM_CHECK produces all kinds of
interesting behaviour: this flag causes g_malloc() and friends to
store one or two hidden fields before the block to use in profiling
and invariant checking.  Plenty of programs try to treat g_malloc'd
blocks as if they were malloc'd, which tends to cause them to crash
when MEM_CHECK or MEM_PROFILE are turned on, but work fine otherwise.

Programs affected include ORBit-0.3.0 and Balsa.

I can see a few solutions, and I'm happy to work them, but it's not up
to me to decide which is appropriate.  Can somebody authoritative
help?

1. Keep gmem.c as it is, and report attempts to free() gmem blocks as
   bugs to the program authors, with patches.  Put in big flashing
   warnings not to do this into the FAQ and documentation.

   This is probably a good move if you want to keep the checking and
   profiling support in glib.

2. Get rid of (or deprecate) the checking and profiling support.
   People can free() and realloc() blocks created by gmem.c.

   This is a good option if people don't use those functions anymore,
   or if it seems too hard to get other authors to conform to the
   interface.

3. Store the hidden flags after the end of the block, rather than
   before the beginning.  This ought to make free() work safely on
   gmem blocks, although it will break realloc().

   This probably fixes the majority of cases where free() is called,
   but makes the other ones much harder to find.

4. Always turn MEM_CHECK on, or turn it on by default for debug
   versions.  This should discourage people from mixing stdlib and
   gmem, at the price of increased memory usage on developer machines.

5. Something else.

-- 
Martin Pool

"Pm fvb jhu ylhk aopz, fvb hyl h jyfwav mylhr!"
               - Caesar VII



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]