Sender: nate AT cartsys DOT com
Message-ID: <35EB451A.FF926ED5@cartsys.com>
Date: Mon, 31 Aug 1998 17:51:38 -0700
From: Nate Eldredge <nate AT cartsys DOT com>
MIME-Version: 1.0
To: Michiel Uitdehaag <m DOT uitdehaag AT imn DOT nl>
CC: djgpp AT delorie DOT com
Subject: Re: keyword "new" causes SIGSEV
References: <Pine DOT SUN DOT 3 DOT 91 DOT 980827140846 DOT 6326M-100000 AT is> <35EAA608 DOT D0F8C199 AT imn DOT nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Michiel Uitdehaag wrote:

> I guess that 0x20 0x67 0x6e 0x69 is ascii (" gni"). Every crash, edx is
> different though (just saw it being "t'no"). No part of my code inserts
> anything like that (not even remotely, I swear).

The 386 stores words least-significant byte first, so what you see is
the reverse of those strings.  "ing " and "on't".  Look more familiar?  

This looks very much like you overrun an array somewhere.

> // line 52
>      frag=GetFragment();
>      fraglen=strlen(frag);
>      fraglen=(fraglen==0)?0:fraglen+1;};
> ...
>  if (fraglen>0) {
>      uri=strcat(uri,"#");
>      uri=strcat(uri,frag);};

Where do you allocate space for `uri'?  It had better get `fraglen+2'
bytes.

> My second questions is: why would malloc() dereference a pointer that is not
> supposed to point to anything? I mean, in:
>         pointer = new char [12];
> pointer gets assigned a value equal to the start of the 12 character block,
> does it not? Who cares where 'pointer' pointed to before. That would be a
> problem for 'delete pointer;'

No, it doesn't look at the value of `pointer' at all.  The problem
occurs when you mess up memory outside that you allocated.  Frequently,
`malloc' uses this space, and hence problems occur.  Imagine an
implementation of `malloc' that stores blocks as a linked list, with the
link at the end of the block.  You might get this:

----------------------------------------------------------------
|   n bytes                                | ptr to next block |
----------------------------------------------------------------

So if you write beyond `n' bytes, you will change the pointer, and
probably point it somewhere invalid.  `malloc' has no reason to believe
this is happening, however, so it happily dereferences the pointer in
its search for a free block, and crashes.

(DJGPP's `malloc' does not actually work this way, but the situation is
similar.)
-- 

Nate Eldredge
nate AT cartsys DOT com