Re: Solutions to gmem.c ENABLE_MEM_CHECK crashes

[Martin Pool <mbp wistful humbug org au>]

On Mon, Oct 19, 1998 at 08:35:09AM -0400, Elliot Lee wrote:
> On Mon, 19 Oct 1998, Martin Pool wrote:
> 
> > 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
> 
> That should not be so, Senor!
> 
> I know I've tested ORBit with MEM_CHECK and/or MEM_PROFILE in the past,
> with no problems. Can you detail what the problems are and where they
> occur (stack trace)?

A `make all' of ORBit-0.3.0 crashes when it tries to build the naming
service using the IDL compiler.  I think this is because the ORBit IDL
compiler exhibits this bug.  Here's a backtrace

   (gdb) file ../../../src/idl-compiler/orbit-idl
   Reading symbols from ../../../src/idl-compiler/orbit-idl...done.
   (gdb) bt
   #0  0x4007b66d in ?? () from /lib/libc.so.6
   #1  0x805d91f in IDL_tree_free_real (p=0x80793b0) at util.c:1422
   #2  0x805d942 in __IDL_tree_free (p=0x80793b0) at util.c:1432
   #3  0x805e0c1 in IDL_tree_free (p=0x80793b0) at util.c:1607
   #4  0x805da37 in IDL_tree_free (p=0x80793e8) at util.c:1464
   #5  0x805a1dd in IDL_ns_ident_to_qstring (ns_ident=0x8079220, 
       join=0x8070de2 "/", levels=0) at ns.c:329
   #6  0x8061401 in IDL_ns_ident_make_repo_id (ns=0x8074a78, p=0x8079220, 
       p_prefix=0x0, major=0x0, minor=0x0) at parser.y:1087
   #7  0x8059bd5 in IDL_ns_place_new (ns=0x8074a78, ident=0x80791e8) at ns.c:223
   #8  0x8060b5f in __IDL_parse () at parser.y:961
   #9  0x805ae88 in IDL_parse_filename (filename=0xbffffcb3 "name.idl", 
       cpp_args=0x8074a70 "", cb=0, tree=0xbffffb4c, ns=0xbffffb48, 
       parse_flags=1, max_msg_level=2) at util.c:293
   #10 0x80495f5 in orbit_idl_to_backend (filename=0xbffffcb3 "name.idl", 
       cpp_args=0x8074a70 "") at main.c:147
   #11 0x804958f in main (argc=2, argv=0xbffffb8c) at main.c:98
   (gdb) up
   #1  0x805d91f in IDL_tree_free_real (p=0x80793b0) at util.c:1422
   (gdb) l
   1417	
   1418		default:
   1419			break;
   1420		}
   1421	
   1422		free(p);
   1423	}
   1424	
   1425	/* Free node taking into account refcounts */
   1426	static void __IDL_tree_free(IDL_tree p)
   
The program died inside libc, I think because free() had tried to use
a gmem block as if it were a malloc block.  This seems to be the usual
failure pattern.

One example of code from ORBit-0.3.0 that exhibits this problem is
(util.c:226):

	if (*filename == '/') {
		linkto = g_strdup(filename);
	} else {
		linkto = (char *)malloc(strlen(cwd) + strlen(filename) + 2);
		if (!linkto) {
			errno = ENOMEM;
			return -1;
		}
		strcpy(linkto, cwd);
		strcat(linkto, "/");
		strcat(linkto, filename);
	}

	tmpfilename = (char *)malloc(strlen(s) + 3);
	if (!tmpfilename) {
		free(linkto);
		errno = ENOMEM;
		return -1;
	}

You can see that the program assigns either a gmem block or a malloc
block to linkto, and later tries to free it.  (It also uses free()
later on on the non-error path.)  This can't be correct.

libIDL seems to always use stdlib, which is probably OK if it a
semi-detached library, but it'll cause problems if it tries to free
pointers it receives, or pass back malloc'd blocks.  

Perhaps it'd be good to replace all calls to malloc(), strdup etc with
gmem calls?

-- 
Martin Pool