From: Eli Zaretskii Newsgroups: comp.os.msdos.djgpp Subject: Re: sigsegv on delete [] Date: Fri, 14 Jan 2000 10:42:12 +0200 Organization: NetVision Israel Lines: 49 Message-ID: <387EE164.35DF45A3@is.elta.co.il> References: <85m241$s2p AT journal DOT concentric DOT net> NNTP-Posting-Host: ras1-p83.rvt.netvision.net.il Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.netvision.net.il 947839431 1264 62.0.172.85 (14 Jan 2000 08:43:51 GMT) X-Complaints-To: abuse AT netvision DOT net DOT il NNTP-Posting-Date: 14 Jan 2000 08:43:51 GMT X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,ru,hebrew To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com 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?