Re: PC segmentation fault

[Wolfgang Lux]

Riccardo Mottola wrote:

> Hi,
> 
> while working in PC, I got a segmentation fault. I tried to reproduce it 
> within GDB, but I couldn't.
> 
> I did a post-mortem check on the core and found this:
> 
> Core was generated by `ProjectCenter'.
> Program terminated with signal 11, Segmentation fault.
> 
> <...>
> 
> #0  0x0fc7c5f6 in codeType (ch=0x8a05b000) at PCParser.m:99
> 99        if ( ((*ch > 0x40) && (*ch < 0x5B)) ||
> (gdb) bt
> #0  0x0fc7c5f6 in codeType (ch=0x8a05b000) at PCParser.m:99
> #1  0x0fc7cc73 in -[PCParser parse] (self=0x7d9c6728, _cmd=0x2fc7b4f8)
>    at PCParser.m:162
> [rest of the backtrace elided]
> the "ch" is:
> (gdb) p ch
> $1 = (unichar *) 0x8a05b000
> 
> 
> 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).

Wolfgang