On Wed, Dec 18, 2002 at 01:32:49PM -0500, [EMAIL PROTECTED] wrote:
> Every so often my mud crashes, I'm not very well versed at GDB so
> this output is not very helpful...
> It appears that the problem is with the line
> buf_free = buf_free->next;
Most likely not.
> however at this point in gdb im stuck...when I try a
>
> p buffer->string
>
> I get
>
> Cannot access memory at address 0x6961432c
[MMM.... a long response, interupted by lunch and probably too wordy.]
Break that apart into bytes: 69, 61, 43, 2c.
Those are most likely ASCII characters: i, a, C and ','
You have a string that is overflowing somewhere.
Suppose you have the following:
char foo[5];
char bar[5];
That will allocate memory something like this (depending on whether the
above are globals or autos and your compiler, of course... the order may
be reversed):
[ ][ ][ ][ ][ ][ ][ ][ ][ ][ ]
That's a series of 10 bytes, with 'foo' pointing to the first byte, and
'bar' pointing to the sixth.
For a bit more clarity, let's put the strings 'baz' and 'baq' into foo
and bar, respectively:
[b][a][z][\0][ ][b][a][q][\0][ ]
Each is a three-character-string (meaning it takes 4 bytes, including
the \0 at the end) and life is peachy and good.
But what happens if we forget that we only have 5 bytes allocated to foo
and write 7 there? Let's write 'garply', which, will be 6 bytes plus
the null:
[g][a][r][p][l][y][\0][q][\0][ ]
That works fine for foo. but bar will now appear to have a string
consisting of the letter 'y' (and the \0, but it wouldn't be a string
without that).
It gets more fun when you have instead of 'char bar[5]' something like
'int bar'. An int (on x86, anyway) is a series of 4 bytes, so it would
look like this:
[b][a][z][\0][ ][04][03][02][01]
(Assuming you had 'bar = 0x01020304', anyway).
And overwriting it with 'garply', as above, would make it:
[g][a][r][p][l][y][\0][02][01]
If read back, bar would now be 0x01020079, assuming x86 and ASCII.
Not at all what you expected.
The bug, then, isn't where bar is read back: it is where bar is
trashed... but how do you know where that is?
Again, go back to what we saw there: "iaC,"
Or.. un-bassackawards, that would be ",Cia" -- maybe a string like
",Ciao!"? Hard to say, though that may give you some hints.
For more hints, look at the area surrounding your variable. Look at the
address of 'buffer->string' (p buffer and it should show you the value
of buffer->string), and snoop around there... look at the 100 or so
bytes before there and you should see more of the ",Cia" that should
give you some context. If you know what string is -before-
buffer->string's allocated memory, you should be able to figure out
where that got inserted and what is assuming it can just scribble
wherever it wants in memory and overwrite things.
