gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ProjectCenter crash with unichar in parser


From: Richard Frith-Macdonald
Subject: Re: ProjectCenter crash with unichar in parser
Date: Sun, 27 Nov 2016 09:15:05 +0000

> On 26 Nov 2016, at 21:48, Riccardo Mottola <address@hidden> wrote:
> 
> Hi,
> 
> 
> ProjectCenter  crashed on me today with Program terminated with signal 11, 
> Segmentation fault.
> 
> 
> I opened the core file and seet his trace:
> 
> #0  codeType (ch=0x11491e685000) at PCParser.m:103
> 103       if ( ((*ch > 0x40) && (*ch < 0x5B)) ||
> 
> a stacktrace:
> 
> (gdb) bt
> #0  codeType (ch=0x11491e685000) at PCParser.m:103
> #1  0x000011491839521d in -[PCParser parse] (self=0x114886e4a490, 
> _cmd=Unhandled dwarf expression opcode 0xf3
> )
>    at PCParser.m:219
> #2  0x0000114918394da0 in -[PCParser classNames] (self=0x114886e4a490, 
> _cmd=Unhandled dwarf expression opcode 0xf3
> )
>    at PCParser.m:81
> #3  0x00001148827e9ce6 in -[PCEditor browserItemsForItem:] (
>    self=0x1148832aee10, _cmd=Unhandled dwarf expression opcode 0xf3
> ) at PCEditor.m:556
> #4  0x0000114831eb3f1d in -[PCProjectBrowser(ProjectBrowserDelegate) 
> browser:createRowsForColumn:inMatrix:] (self=0x11482c42e450, _cmd=Unhandled 
> dwarf expression opcode 0xf3
> )
>    at PCProjectBrowser.m:544
> #5  0x000011487858ff93 in -[NSBrowser(Private) _performLoadOfColumn:] (
>    self=0x11488d037c10, _cmd=Unhandled dwarf expression opcode 0xf3
> ) at NSBrowser.m:3339
> #6  0x000011487858d0e1 in -[NSBrowser addColumn] (self=0x11488d037c10, 
> _cmd=Unhandled dwarf expression opcode 0xf3
> )
>    at NSBrowser.m:954
> 
> I ask myself, how can it crash in this place? The unichar is valid and there, 
> I can print it out:
> 
> (gdb) p ch
> $1 = (unichar *) 0x11491e685000
> Current language:  auto; currently

If you look at line 103, it's checking *ch ... so it thinks ch is a pointer to 
a unichar.
But, the code printed for line 103 is incomplete (the || operator at the end 
implies that there's more in the expession), so the problem could be something 
els you didn't include in the email.

Assuming the problem is the dereference of ch, it will crash if ch points to 
non-existent/inaccessible memory or (some architectures) if the memory location 
is not on the correct boundary for the data type.
In this case you printed the pointer and it clearly isn't null or on an odd 
boundary, so I guess it's a non-existent memory location.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]