Date: Tue, 19 May 1998 15:41:08 +0200 (MET DST)
Message-ID: <199805191341.PAA15048@basement.replay.com>
Subject: Execution finished before started!
From: nobody AT REPLAY DOT COM (Anonymous)
Organization: Replay and Company UnLimited
Mail-To-News-Contact: postmaster AT nym DOT alias DOT net
Newsgroups: comp.os.msdos.djgpp
Lines: 52
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk


I think I am having a problem with memory leaks, so I am using memory
checkers to keep track of wild pointers.

At first I attempted a port of a library called MEMDEBUG and linked it with
my code.  It worked, but I didn't like it.  Then I went to DMALLOC, which
was difficult to port because it wants to be a malloc replacement rather
than wrap around it.  I noticed that the successfully linked code abruptly
exited from rhide (with a SIGABRT) and a display of the assembly debug
window;  it never got into main().

Then I went to something called DBMALLOC that shows promise, another library
set up for Unix but something that is not too hard to port.  Damn it all
if it didn't do the same thing.

Leaving rhide to use gdb doesn't help.  The following is the conversation
that gdb and I had from a W95 DOS box:

-----------------------------------
C:\WINDOWS>gdb
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (go32), Copyright 1996 Free Software Foundation, Inc.
(gdb) cd \obj
Working directory \obj
 (canonically c:/obj).
(gdb) file myprog.exe
Reading symbols from myprog.exe...done.
(gdb) b 106
Breakpoint 1 at 0x3640f: file myprog.c, line 106.
(gdb) r -d
Starting program: \obj/myprog.exe -d
Load failed for image \obj/myprog.exe

C:\OBJ>
-----------------------------------

'symify' reveals nothing but the command itself in the output file
(assuming a clear screen).

Clearly there is something bad happening between the startup code
and the malloc (wrapper?) functions in the malloc debugging library.
I can't imagine how they could prevent a simple startup.

What would cause the SIGABRT I see in rhide?  Is the start code (from
crt0()? calling a malloc() in the debug library.  What pisses me off
is that objdump of the library itself shows _malloc referenced, but
I think it is a call by the wrapper functions of the library to the
standard library malloc().