Re: GNUstep Code Freeze

[Fred Kiefer]

On 01.02.2012 02:21, Germán Arias wrote:
> As far as I can see, when [[NSScrollView alloc] initWithFrame: r] is
> called at line 173. The
> ScrollView gets an NSClipView as its content view (see -initWithFrame:
> in NSScrollView.m).
> But looking in NSClipView.m a don't see any initialization of
> _documentView.

Looks like you found the cause of the problem. We are asking a nil view 
for its frame. I am used to this case crashing on Sparc processors, it 
is new to me that gcc 4.6 now also manages to corrupt the stack on i386 
when it has to return a structure from a nil call. Somebody will have to 
write a bug report and a test case for gcc here.

The code here in GSThemeInspector was wrong all the time, but it used to 
work, which means the only difference can be in gcc. I will fix the code 
in gui. Could you please test again after that? I still cannot reproduce 
the problem on my 64bit machine.

> On 2012-01-31 16:40:09 -0600 Riccardo Mottola
> <address@hidden> wrote:
>
> > Hi,
> >
> > Fred Kiefer wrote:
> > > That is interesting, your selector string contains the additional
> > > characters "Abnai\031". Where could these come from?
> > >
> > > As I wrote I cannot reproduce it here and it will require somebody to
> > > debug this who is actually seeing the problem. Could you please set a
> > > breakpoint at line 180 in GSThemeInspector.m and start inspecting
> > > stuff there?
> > Breakpoint 1, -[GSThemeInspector update:] (self=0x82fa6a4,
> > _cmd=0xb7fcea88,
> > sender=0x82e2684) at GSThemeInspector.m:181
> > 181 r = [[s documentView] frame];
> > (gdb) po s
> > h=-&- v=-&- <NSScrollView: 0x829f084> f={x = 10; y = 10; width = 252;
> > height = 225} b={x = 0; y = 0; width = 252; height = 225}
> >
> > (gdb) po content
> > h=-&- v=-&- <NSView: 0x83021d4> f={x = 1; y = 9; width = 272; height =
> > 388} b={x = 0; y = 0; width = 272; height = 388}
> >
> > if I type "n", I get this sequence:
> > 181 r = [[s documentView] frame];
> > (gdb) n
> > 178 [content addSubview: s];
> > (gdb) n
> > 179 RELEASE(s);
> > (gdb) n
> > 181 r = [[s documentView] frame];
> >
> > this looks corrupt, doesn't it?
> > Anyway, if I continue with "n" I get:
> > 181 r = [[s documentView] frame];
> > (gdb) n
> > -[GSThemeInspector update:] (self=0xb7e4f103, _cmd=0x839f4ec,
> > sender=0xb7fcea88) at GSThemeInspector.m:182
> > 182 v = [[NSTextView alloc] initWithFrame: r
> > 181 r = [[s documentView] frame];
> > (gdb) n
> > 182 v = [[NSTextView alloc] initWithFrame: r];
> > (gdb) n
> > unknown type eos. The next step in theming, but with a strong root in
> > NeXT.
> >
> > Program received signal SIGABRT, Aborted.
> > 0xb7fe2424 in __kernel_vsyscall ()
> >
> > If I rerun and stop just before the crash, I can see:
> > (gdb) n
> > 182 v = [[NSTextView alloc] initWithFrame: r];
> > (gdb) p r
> > $1 = <optimized out>
> > (gdb) p s
> > $2 = (struct NSScrollView *) 0x81afe8c
> > (gdb) po s
> > h=-&- v=-&- <NSScrollView: 0x81afe8c> f={x = 10; y = 10; width = 252;
> > height = 225} b={x = 0; y = 0; width = 252; height = 225}
> > (gdb) n
> > 181 r = [[s documentView] frame];
> > (gdb) n
> > -[GSThemeInspector update:] (self=0xb7e4f103, _cmd=0x8140d84,
> > sender=0xb7fcea88) at GSThemeInspector.m:182
> > 182 v = [[NSTextView alloc] initWithFrame: r];
> >
> > This is absolutely confusing, I think the debugger is spitting out crap.

It is confusing, but could be perfectly legal. Modern compiler rearrange 
the code in ways they see better fit for nowadays processors. This is 
quite annoying and there is a switch to stop gcc from doing so. I always 
thought that it is included in the debug settings that GNUstep is using 
as the default, but I experience the same problem here.