Mail Archives: djgpp/1998/08/31/21:02:17
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
- Raw text -