Solutions to gmem.c ENABLE_MEM_CHECK crashes
- From: Martin Pool <mbp wistful humbug org au>
- To: Seth Burgess <wilber wilberworks com>
- Cc: gtk-devel-list redhat com
- Subject: Solutions to gmem.c ENABLE_MEM_CHECK crashes
- Date: Mon, 19 Oct 1998 18:55:25 +1000
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]