Clicking a single catalog item in the sidebar crashes QS

[pjrobertson]

Noticed this when looking at #385

If you click anywhere on an item other than on the checkbox QS instantly crashes for me.

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000008
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   com.apple.AppKit                0x97894524 -[NSFont __isSystemFont] + 48
1   com.apple.AppKit                0x9792efec -[NSFont screenFontWithRenderingMode:] + 84
2   com.apple.AppKit                0x97dd9f65 +[NSStringDrawingTextStorage _fastDrawString:attributes:length:inRect:graphicsContext:baselineRendering:usesFontLeading:usesScreenFont:typesetterBehavior:paragraphStyle:lineBreakMode:boundingRect:padding:scrollable:] + 374
3   com.apple.AppKit                0x9792ea05 -[NSString(NSExtendedStringDrawing) boundingRectWithSize:options:attributes:] + 2218
4   com.apple.AppKit                0x97931350 -[NSString(NSStringDrawing) sizeWithAttributes:] + 80
5   com.blacktree.QSInterface       0x0011f80f -[QSObjectCell drawTextForObject:withFrame:inView:] + 420
6   com.blacktree.QSInterface       0x0011ef79 -[QSObjectCell drawInteriorWithFrame:inView:] + 265`

[hmac]

I can confirm this in the current master branch, but it doesn't seem to happen in ß60.

[skurfer]

I wonder if it was introduced with #363, as discussed on the developers list.

I’ll see if moving things around in the header file makes any difference.

[skurfer]

Changing the order didn’t prevent the crash. I think it might be line 487 of QSObjectCell.m. That depends on the value of nameAttributes, which is something I monkeyed with in the commit mentioned above, but I’m not sure exactly what the problem is.

[pjrobertson]

Have you tried doing a git bisect around that commit just to make sure
that's where the bad changes are?

On 21 June 2011 05:59, skurfer <
reply@reply.github.com>wrote:

Changing the order didnt prevent the crash. I think it might be line 487
of QSObjectCell.m. That depends on the value of nameAttributes, which is
something I monkeyed with in the commit mentioned above, but Im not sure
exactly what the problem is.

Reply to this email directly or view it on GitHub:
#386 (comment)

[pjrobertson]

So I've done a git bisect and found that the dodgy commit is
e0893fb

@skurfer, can I let you continue from here since I never really looked at your interface changes?
From a brief glance, surely setting the font to nil is a really bad thing to be doing?

[skurfer]

Have you tried doing a git bisect around that commit just to make sure that's where the bad changes are?

No, because honestly, I haven’t figured out what’s that’s all about yet. :)

From a brief glance, surely setting the font to nil is a really bad thing to be doing?

Maybe, but it should be safe. nameFont is only used in one place and prior to being used, its value is checked and if nil, it’s set to (what should be) a valid NSFont. nil in this context is supposed to indicate “the interface didn’t set the font so use defaults”. Ideally, we’d just set these defaults in initTextCell, but they’re relative to cellFrame which doesn’t exist at that point.

I’ll step through that method in the debugger and see if I can figure out the problem.

[pjrobertson]

Have you tried doing a git bisect around that commit just to make sure that's where the bad changes are?

No, because honestly, I haven’t figured out what’s that’s all about yet. :)

git bisect is pretty easy to get the hang of, and a really powerful tool for finding where problems were introduced. You literally just do:
git bisect start to start the bisect. git bisect good COMMIT-SHA with the SHA of a good commit (e.g. here it would have been the ß60 release commit), git bisect bad COMMIT-SHA with the SHA of a bad commit (e.g. here it would have been the most recent).
From there, git automatically narrows down to find the bad commit. You just need to rebuild QS, check so see if the bug's there or not and type git bisect good or git bisect bad depending on whether the bug is/isn't in the build you've just made. :)

Maybe, but it should be safe

I guess so, yeah. It looks like QS is crashing on isSystemFont (or near it) so my guess is it's still font related.
Cheers for taking this over :)