Date: Thu, 23 Sep 1999 11:15:08 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: GAMMELJL AT SLU DOT EDU
cc: djgpp AT delorie DOT com
Subject: Re: Problem with new malloc.c attn: Eli Zaretskii
In-Reply-To: <01JG9MV9JK9U8WZVG8@SLU.EDU>
Message-ID: <Pine.SUN.3.91.990923111445.10652S-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Wed, 22 Sep 1999 GAMMELJL AT SLU DOT EDU wrote:

>      What happens when I try to run the compiled program
>                           c:\codename
> is this:  many screens of error information scroll by with
> no stopping until I press "pause".

Try to press PAUSE immediately after the Enter key that launches the
program.

>      The same remarks apply if instead of | more I redirect the
> output to a file using
>               c:\codename >error.txt.

The error messages usually go to stderr, not to stdout.  Did you try
to redirect stderr alone with the REDIR program?  See section 6.14 of
the FAQ for more details.  That section also lists a couple of other
solutions for capturing screen output; perhaps one of them will help
you, if REDIR doesn't.

>      Now, I really did not understand what it is that you want
> me to post.

The crash message: the registers' dump, the stack frame traceback, the
works.  Run SYMIFY on the traceback, so that the functions' names
appear on it, because the numeric addresses are meaningless.

>      I can hand copy the last bit of the error messages going
> to the screen: 
>         Exiting due to signal SIGSEGV
>         General Protection Fault at
>                eip=00001f47
>         eax=6574649 .................................
>         .................exp=0005c380 program=c:\codename.exe
>         cs=set 0097 base 10000000 limit=0006ffff
>         .
>         .
>         ss
>         Call frame traceback EIPs:
>         0x00001f47
>         .
>         .
>         0x6f697461
> I could hand copy what I have omitted if it is of any use to you.

I need the full text of this message, and the most important message
is the first one printed, not the last one, because the others might
not be related to the real problem.

I really see no way I could help you without this information, except
reiterate that problems which go away when you fall back to the old
malloc are due to memory overruns in your code.

>      Another fact (whose relationship to the above I cannot
> imagine) is that if I delete the destructors (see the lines
> marked "destructor for realmp" in the example which I posted)
> from my class definitions I do not have any problem compiling
> and running with the new malloc.c.

Probably because the destructor calls `free', and `free' crashes
because your code have overwritten the hidden information beyond the
end of the buffer that `malloc' (via `new') handed to you.  `free'
needs that hidden information to put the released memory on the free
list.

Perhaps you could try to compile and link your program with some
malloc debugger, such as YAMD.  It might pinpoint the code that
overwrites the malloc'ed memory.