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 _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
