Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clicking a single catalog item in the sidebar crashes QS #386

Closed
pjrobertson opened this issue Jun 20, 2011 · 7 comments
Closed

Clicking a single catalog item in the sidebar crashes QS #386

pjrobertson opened this issue Jun 20, 2011 · 7 comments
Assignees

Comments

@pjrobertson
Copy link
Member

pjrobertson commented Jun 20, 2011

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
Copy link

hmac commented Jun 20, 2011

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

@skurfer
Copy link
Member

skurfer commented Jun 20, 2011

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
Copy link
Member

skurfer commented Jun 20, 2011

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
Copy link
Member Author

pjrobertson commented Jun 20, 2011

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
Copy link
Member Author

pjrobertson commented Jun 20, 2011

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
Copy link
Member

skurfer commented Jun 21, 2011

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
Copy link
Member Author

pjrobertson commented Jun 21, 2011

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 :)

@ghost ghost assigned skurfer Jun 22, 2011
@skurfer skurfer closed this as completed Oct 11, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants