Date: Thu, 27 Aug 1998 14:09:07 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Mike Rusch <ruschtmm AT newnorth DOT net>
cc: djgpp AT delorie DOT com
Subject: Re: keyword "new" causes SIGSEV
In-Reply-To: <35E4B0FB.D8D8AABC@newnorth.net>
Message-ID: <Pine.SUN.3.91.980827140846.6326M-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Wed, 26 Aug 1998, Mike Rusch wrote:

>                                         What is your choice?
> 01234567Exiting due
>  to signal SIGSEGV
> General Protection Fault at eip=0000c1d8
> eax=0000001c ebx=00000002 ecx=fffffffc edx=07200720 esi=00000018
> edi=00058cc8
> ebp=00058c58 esp=00058c50 program=C:\DJGPP\MIKE\COLLEGES.EXE

The EDX register looks like text to me (0x20 is a blank, 0x07 is a ^G
character), and _malloc+192 dereferences a pointer in EDX.  So, like I
said: some code in your program writes past the limits of an allocated
buffer, and scroggs the malloc's internal data structures.  Maybe the
contents of EDX can help you find the villain: is there any code that
puts ^G (Bell) character into some buffer?

> The 01234567 after "What is your choice?" was generated by debugging
> code I inserted just before the call to effstrcpy.  It shows that on the
> 7th call the error occurred (just like before).

The problem is most probably not in the place it crashes, it happens
before the crash.  Some code that is executed prior to that call to
`malloc' overwrites a buffer allocated by another call to `malloc'.
You need to find that place by tracing all allocations and how the
buffers allocated are used.

> Now, I also tried changing malloc to xmalloc, calloc, and alloca.  The
> former two just call malloc, and I got the same error.  However, when I
> used alloca, everything worked fine.  I'm afraid that was just luck,

Using alloca is sweeping the problem under the carpet: alloca
allocates the memory off the stack, and so doesn't detect the
problem.  You still have some code that overwrites memory it doesn't
own.

Once again, the problem is NOT where it crashes, it's somewhere before
that.  The crash is caused by some code that overwrites internal
structures of `malloc' by incorrectly using a buffer allocated by it.