Re: Weird crash related to NSFont usage

[Fred Kiefer]

Andreas Höschler wrote:
> 
> I have isolated the cause of a crash to the following method in a
> NSSubView subclass.
> 
> - (void)drawRect:(NSRect)rect
> {
> [super drawRect:rect];
> 
> ...
> [[NSColor redColor] set];
> #ifdef __APPLE__
> * [mark drawAtPoint:NSMakePoint(point.x + 5, point.y + 4)
> withAttributes:[NSDictionary dictionaryWithObjectsAndKeys:[NSFont
> labelFontOfSize:10.0], NSFontAttributeName, [NSColor redColor],
> NSForegroundColorAttributeName, nil]]; // the font stuff crashes GNUstep
> *#else
> [mark drawAtPoint:NSMakePoint(point.x + 5, point.y + 4)
> withAttributes:[NSDictionary dictionaryWithObjectsAndKeys:[NSColor
> redColor], NSForegroundColorAttributeName, nil]];
> #endif
> ...
> }
> 
> If I put the [NSFont labelFontOfSize:10.0], NSFontAttributeName in the
> dictionary the app crashes somewhere in the depth of gui on GNUstep
> while it works flawlessly on MacOSX. Any idea what might cause the
> problem? For now I have worked around the problem withthe above #ifdef
> statement but it would be good to understand what causes the trouble in
> GNUstep.
> 

I expect that this also happens on Solaris. Now this system is notorious
for segfaulting on methods being send to nil. What I would expect to
happen is that the NSFont method returns with a nil object, as you don't
have a matching font installed (which font it is looking for depends on
the backend you use, but you don't seem to remember which one it is :-).
And somewhere deep down within GNUstep we don't catch the case, where
the font attribute is set, but is nil. I will check that theory, in the
meantime you could test, what your labelfont looks like.

Cheers
Fred