[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PC segmentation fault
From: |
Riccardo Mottola |
Subject: |
Re: PC segmentation fault |
Date: |
Sat, 21 Sep 2013 01:30:14 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 |
Hi,
Wolfgang Lux wrote:
Riccardo Mottola wrote:
but how can I get a segmentation fault in the line shown in #0 ? it is only a
comparison and the char value is apparently valid, I see no array access or
other pointer usage.
Richard already answered the question why the code could fail in frame #0.
And looking a bit further I see this for loop with a suspicious loop end
condition in the parse method at line 159:
for (i = 1; i < _length+1; i++)
If I understand the code of the parse method correctly, there is the possibility
that it may access the character at offset _length, which is immediately *after*
the end of the malloc'd buffer. If you still have the core dump available you
could check the values of the local variable i and the attribute _length in frame
#1. I suspect they are equal. The fix then is obvious: Change the loop termination
condition to i < _length (but you should do that regardless whether my
suspicion is right or not, because the condition is wrong anyway).
Indeed, had a better look at the code and had the same suspicion,
however it looks clear to me that it was done on purpose and I was
trying to understand why. But it looks just wrong, at the end, the thing
is walking through a string bugger and skips the first char.
first, why can't I just "p _length" ? why is it not in context?
(gdb) p i
$1 = 1176
(gdb) p _length
No symbol "_length" in current context.
However, I put in an NSLog and indeed, i = _length
It is interesting that I get this bug only in this file and not for
every file. I suppose it has to be termination dependent and usually
exists before.
anyway, changing the range to
for (i = 1; i < _length; i++)
breaks the parser: I don't get any crashes, but it doesn't parse any
methods in any file! using <= makes it work, but it will of course still
crash (and crashes). Thus the code expects to be able to peek "one after".
An extremely stupid hack would be to make the buffer one bigger and zero
the last char, but I think that something in the cycle condition can be
tweaked so that it is not needed
Riccardo