Mail Archives: djgpp/2000/01/14/21:27:34
well, i don't understand why this fixed the problem i was having, but maybe
you could explain it. it seems in a member function of a another class i
forgot to delete an array i created for local use. so the member function
would use new, but the array wasn't deleted ever. why would this cause a
sigsegv in deleteing something else? i know it creates a memory leak and
such, but having the allocation out there shouldn't screw other allocations
up, should it? anyway, i added the delete and haven't had the sigsegv show
up since.
thanks for your help
Chad Rabbitt
chad AT rabbitt DOT com
"Chad Rabbitt" <chad AT rabbitt DOT com> wrote in message
news:85ncfk$6a8 AT chronicle DOT concentric DOT net...
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 -