Mail Archives: djgpp/1998/08/05/02:14:47
Greetings,
As you might recall, I had a problem in runnng fsdb on even the
simplest of hello.c. I checked the entire run using gdb and have a
tentative idea about what could be happening.
The problem manifests itself through dereferencing an invalid pointer and
is almost certainly caused due to corrupting the linked list of memory
areas (of size 128, bucket = 4, in this case) maintained by malloc. Since
the memory size is less than 4K, the memory areas of 128 are contiguous
which makes their linked list particularly easy to watch. In my case the
list is:
0x6d07c
0x6d0fc
0x6d17c
0x6d1fc
0x6d27c, and so on <32 items>
I also know that no area of this size (128) is freed upto the crash, so
that I am certain about the contiguity of the list. The problem occurs
when one of these peices (the one beginning at 0x6d0fc) which can be which
is limited to 120 bytes overwrites the pointer to the next member --- in
fact it decreases it by one, converting 0x6d17c to 0x6d17b. The pointer to
the succeding member of the list then becomes 0x6d1fc65 (65 is actually
junk) instead. When this is derefenced the program crashes.
Assuming that the last allocated array was the one that overstepped its
bounds, (120 is close to 128), I find that this allocation was made in the
function process_coff in the file src/debug/common/syms.c, and is handed
out to f_lnno which points to an array of pointers to line numbers.
However I find nothing offending in its behaviour, or atleast nothing
obviously offending.
Since I know which memory address is being changed (decremented in this
case), I would like to know if gdb can be instructed to stop if the
contents of a particular address change, which might help me to
understand better the exact location at which the array overstepped.
Also, I would be grateful to know, if the code in process_coff is
particularly affected by the subtle problems of debugging a debugger,
something I know very little about.
Thank you and with warm regards
Gurunandan
- Raw text -