From: "Chad Rabbitt" 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: <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" 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?