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
<riccardo.mott...@libero.it> 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.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
