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

Contacts plugin causes freeze #1957

Closed
mfloreen opened this issue Oct 21, 2014 · 13 comments · Fixed by #1970
Closed

Contacts plugin causes freeze #1957

mfloreen opened this issue Oct 21, 2014 · 13 comments · Fixed by #1970

Comments

@mfloreen
Copy link

@mfloreen mfloreen commented Oct 21, 2014

The new update has caused the Contacts plugin to stop working. Any attempt to call up a contact locks Quicksilver up with the beach ball, and it must be forced-quit.

@mfloreen mfloreen changed the title Contacts plugin now causes freeze Contacts plugin causes freeze Oct 21, 2014
@mrstanwell
Copy link

@mrstanwell mrstanwell commented Oct 27, 2014

I started seeing this after upgrading to 1.2 (on OSX 10.8.5). At first I thought it was Contacts plugin, but through process of elimination I determined that it was related to having both Contacts and Mail plugins enabled. With only Contacts plugin, no hang occurs. With Contacts and Mail enabled, QS always freezes after the third char on a Contact search is typed. With Mail only enabled nothing freezes and I can compose emails to a manually-typed email address, but without the Contacts plugin I can't obviously mail to a contact.

So if you disable the Mail and EmailSupport plugins and restart QS, it should stop hanging on contact lookup. Unfortunately, you won't be able to send email with QS…

BTW, I get no meaningful log msgs when this happens.

@skurfer
Copy link
Member

@skurfer skurfer commented Oct 29, 2014

Thanks for the information. The E-Mail Support plug-in does some checking on the things in the first pane to see which actions should appear. That might explain it, but it doesn’t do anything particularly expensive, and it should happen as soon as the contact is selected. Not after the third character.

@mrstanwell
Copy link

@mrstanwell mrstanwell commented Oct 29, 2014

Okay, the third char bit is a red herring. When I was trying it out, it was actually taking me three chars to get to the contact in the first place. It will in fact lock as soon as the contact is selected. For example, if I hit a char then bring up the "/" menu to scroll through alt selections, it will lock as soon as I hit a contact.

It looks like it's just blocking, not doing anything expensive. It's not consuming any detectable CPU.

I've run through more use cases and have triggered a block a few ways, but never 100% consistently. Without looking at code, this smells like a race condition relating to the Actions list and the icons for the actions. Here's the most reliable way I've found to trigger it so far:

  1. Quit QS
  2. Clean QS settings out completely:
  • $ rm -fr ~/Library/Preferences/com.blacktree.Quicksilver.plist
  • $ rm -fr ~/Library/Application\ Support/Quicksilver
  • $ rm -fr ~/Library/Caches/Quicksilver
  • $ rm -fr ~/Library/Caches/com.blacktree.Quicksilver
  1. Launch QS and go through initialization. DO NOT SELECT ANY PLUGINS. Just "Continue" everything.
  2. Quit QS and relaunch (to start clean).
  3. Invoke QS, bring up Preferences.
  4. Go to Plugins. The plugin list is always empty for me, so I have to reload the list.
  5. Check Apple Mail and Contacts plugins only.
  6. Relaunch QS (to start clean again).
  7. Bring up Preferences. Select "Actions" in the left side menu. Choose "Contacts" in Action Type. Generally, I observe that the action icons are not always the icon for the Contacts app, but instead are default gears.
  8. In the Type list, arrow down to "Email Addresses". This almost always blocks.

Now, occasionally in step 9 I see the correct icons for the Contacts actions. When I do, arrowing down to Email Addresses also shows correct icons, and no blocking takes place. However, if I quit QS and start again at step 8, I can usually trigger the block.

I hope this is useful info. If you cannot reproduce it, I could try building from source and getting a thread dump during the block. However, I've never really done any Objective-C development (though I know C++ and Java), so there'd be a bit of a learning curve.

@tiennou
Copy link
Member

@tiennou tiennou commented Oct 29, 2014

I hope this is useful info. If you cannot reproduce it, I could try building from source and getting a thread dump during the block.

You can get one of those using Activity Monitor instead, no need to go to the source.

@mrstanwell
Copy link

@mrstanwell mrstanwell commented Oct 29, 2014

Ah. Who knew. ;-)

Here're the results of "Sample Process" in AM:
http://pastebin.com/kvKhCDfp

EDIT: put that trace in a pastebin.

@tiennou
Copy link
Member

@tiennou tiennou commented Oct 29, 2014

Aaaand the winner is Thread_8266223. I think.

It's holding the runtime lock (because of the various libobjc functions), and then tried to do stuff with bundles, which is locked by Thread_8266219.

@skurfer
Copy link
Member

@skurfer skurfer commented Oct 30, 2014

I think the problem is that QSActionHandler is calling setQuickIconForObject: on the main thread and loadIconForObject: on a background thread. Both of those call -[QSResourceManager imageNamed:inBundle:], which locks the resource manager. (Does it need to? Even if it does, probably not for the whole method.) I can’t reproduce it, but maybe because I have an SSD and one thing is able to load before the next one starts. I can see how it would be a problem, though.

One tip on the above steps: Removing the preferences might not do the trick in 10.9 or later because the prefs are aggressively cached. Running defaults delete com.blacktree.Quicksilver should do it though, because it tells the system something is changing and it should clear the cache.

@skurfer
Copy link
Member

@skurfer skurfer commented Oct 30, 2014

See #1871, which was intended to fix #1861. Maybe QSResourceManager should be doing things on the main thread, instead of wrapping them in @synchronized.

@skurfer skurfer closed this as completed Oct 30, 2014
@skurfer skurfer reopened this Oct 30, 2014
@skurfer
Copy link
Member

@skurfer skurfer commented Oct 31, 2014

See if this build works any better for you. (I’m not able to reproduce the problem locally.)

If so, I’ll put a pull request together.

@maru-sama
Copy link
Contributor

@maru-sama maru-sama commented Oct 31, 2014

Hello, I tested this build and Quicksilver no longer crashes if the mail support plugin is installed. There is one strange thing though. IF the gmail plugin is NOT installed as well I see the following error..

31/10/14 18:48:57,514 Quicksilver[542]: Mail mediator com.google.GmailNotifier not found

And something else. I tried to reproduce the problem now and of course I fail. I upgraded to Mavericks on this machine in the meantime and I cannot get this hang to happen again.

@mrstanwell
Copy link

@mrstanwell mrstanwell commented Oct 31, 2014

So far I've been unable to reproduce the deadlock with this build. That includes with all the rest of my plugins installed, settings, etc.

@maru-sama: I don't see the GmailNotifier error. I also haven't ever installed the gmail plugin, either.

Thanks, Rob! You guys are great.

@skurfer
Copy link
Member

@skurfer skurfer commented Nov 1, 2014

Good. I think I just made it far less likely to dead-lock, but maybe I fixed it. I’ll look things over a bit more and submit a pull request.

If you have the Gmail plug-in selected in Preferences → Handlers, it will try to load it. If it’s not installed, QS will complain. It’s nothing serious and easy to fix. (Either install the plug-in, or choose the handler you actually use.)

@mfloreen
Copy link
Author

@mfloreen mfloreen commented Nov 1, 2014

Works perfectly for me too. Thanks, Rob!

Reply to this email directly or view it on GitHub.

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

Successfully merging a pull request may close this issue.

5 participants