delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/01/14/12:07:39

From: "Chad Rabbitt" <chad AT rabbitt DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: sigsegv on delete []
Date: 14 Jan 2000 09:39:48 EST
Organization: Concentric Internet Services
Lines: 60
Message-ID: <85ncfk$6a8@chronicle.concentric.net>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000112090254 DOT 28074Q-100000 AT is> <85m241$s2p AT journal DOT concentric DOT net> <387EE164 DOT 35DF45A3 AT is DOT elta DOT co DOT il>
NNTP-Posting-Host: ts006d18.lon-co.concentric.net
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

thanks for your responses.  i'll spend some time looking around my code.
i'll post what i find out.

Chad Rabbitt
chad AT rabbitt DOT com

"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il> wrote in message
news:387EE164 DOT 35DF45A3 AT is DOT elta DOT co DOT il...
Chad Rabbitt wrote:
>
> i really don't believe i'm running over the array bounds in
> either case.

Believe it ;-).

> what information does dynamic memory store besides the actual
> data?  i mean what is stored besides the data in djgpp dynamic memory?  it
> seemed that in gdb, eight bytes  extra were stored before and after the
> array, outside the defined size of the array.

The info stored there are pointers to the previous and next memory blocks.
These pointers join the memory blocks managed by malloc into a chain which
it
can follow to find free blocks and join small blocks into larger ones.  If
you overwrite that info with some data, these functions will crash.

See the sources of malloc and free (in djlsr203.zip) if you want the whole
story.

> these eight bytes before and
> after the array never changed after the new and before the delete.

The crash dumps suggest otherwise:

> Exiting due to signal SIGSEGV
> General Protection Fault at eip=000160e7
> eax=002a2f30 ebx=000a8b94 ecx=000a8b94 edx=002c9ac8 esi=000aaabc
> edi=000a8bcc
> ebp=000a98d8 esp=000a98cc program=M:\USERS\RABBITT\DST\SEADST.EXE
> cs: sel=00a7  base=10000000  limit=000bffff
> ds: sel=00af  base=10000000  limit=000bffff
> es: sel=00af  base=10000000  limit=000bffff
> fs: sel=008f  base=0003efb0  limit=0000ffff
> gs: sel=00bf  base=00000000  limit=0010ffff
> ss: sel=00af  base=10000000  limit=000bffff
> App stack: [000a9b68..00029b68]  Exceptn stack: [00029ac4..00027b84]

Here, I'm guessing that EAX holds the garbled pointer (you can find out if
this is true using the technique described in section 12.2 of the FAQ).  Its
value looks like a text string "*/".  Do you have this text anywhere in your
program?

> General Protection Fault at eip=00016167
> eax=cc8195a0 ebx=000a909c ecx=000a912b edx=cc840138 esi=000a912b
> edi=73206568

Here, both EAX and EDI are garbled, and EDI looks like part of a string
"he s".  Does this ring a bell?


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019