Skip to content

Freeze on "Open With..." action #2020

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

Closed
ar-rm opened this issue Jan 24, 2015 · 13 comments
Closed

Freeze on "Open With..." action #2020

ar-rm opened this issue Jan 24, 2015 · 13 comments

Comments

@ar-rm
Copy link

ar-rm commented Jan 24, 2015

Steps:

  • QS
  • Command-G
  • Tab
  • Type "w" to get "Open With..." action. (Or press the down-arrow to reveal all of the potential actions. I can move through the list until I hit "Open With...".)

Result:

  • QS Freezes.
  • I have to force quit it.
  • After the force quit/restart of QS, the following is logged to system.log (probably not related):
Jan 24 12:44:24 com.apple.xpc.launchd[1] (com.blacktree.Quicksilver.131808[6515]): Service exited due to signal: Killed: 9

This is a crashlog from around the time of the crash, but it's possible that it's from another crash and not related: https://gist.github.com/ar-rm/0442c3e57fb873ca3905

Versions:

QS: 1.2.2 (4011)
OS: 10.10.1

Relevant (maybe): I was previously using QS 1.0.0 (4000) and this wasn't an issue... But other things started to be, so I upgraded to 1.2.2 and this issue started. The exact same thing happened with another 10.10.1 install I was testing on an external HD. I upgraded QS to 1.2.2 and this started.

Which Plug-In does "Open With..." come from? I'd like to try disabling it. Or is it built in?

I found issue #1783, but don't know if it's actually related.

Thanks.

@skurfer skurfer changed the title Crash on "Open With..." action Freeze on "Open With..." action Jan 27, 2015
@skurfer
Copy link
Member

skurfer commented Jan 28, 2015

Do you have anything in your catalog that might be an alias to a folder on an unreachable network drive?

@ar-rm
Copy link
Author

ar-rm commented Jan 29, 2015

I doubt it, but that's a good thought.

I went through all of the catalogs, disabled each of them per major group (i.e.: Applications, Plugins, System, etc.) and ran a "Catalog Rescan" after each. Same result. The only slight difference is the Actions popup appears (with "Open" at the top and "Open With..." just below). But it's still frozen. I don't know why that changed.

I updated to 10.10.2 yesterday as well.

@skurfer
Copy link
Member

skurfer commented Dec 14, 2015

Does this still happen with Quicksilver 1.3.4?

@ar-rm
Copy link
Author

ar-rm commented Dec 14, 2015

I don't know. Sometime shortly after this post I reverted to OS 10.9.5 and QS 1.0.0. I've been hessitant to update since :-)

You think 1.3.4 (or some other earlier version) resolved this?

@skurfer
Copy link
Member

skurfer commented Dec 14, 2015

If it was a network drive, yes. Otherwise, I’m not sure, but a lot has changed so it might be worth a look.

@ar-rm
Copy link
Author

ar-rm commented Dec 15, 2015

I just upgraded to 1.3.4 (4016).

Same result.

  • QS freezes
  • The only way out is to force quit

Some other, hopefully useful, info:

  • Activity Monitory does NOT list QS as "Not Responding". In fact, QS seems to travel up and down the CPU tab as it normally would... All while the UI is stuck on the screen :-) .
  • Console: I don't think anything related was reported. I cleared the view just before testing and nothing was written during the freeze.
  • I tried un-checking all "User" catalog items. Still freezes.
  • I disabled the "Open with..." action: NO FREEZE. I was able to arrow down into the additional actions without freezing. As soon as I re-enabled it and retested, QS froze as it did before.

Here are a "Sample" and "Open Files & Ports" from Activity Monitor, taken while QS was frozen:
QS-Open with Freeze-2015.12.15-Sample of Quicksilver.txt
QS-Open with Freeze-2015.12.15-Open Files and Ports.txt

I haven't deleted any preferences yet in case there are still some other steps to diagnose this.

Thanks for checking in on this so far after I initially reported it!

@ar-rm
Copy link
Author

ar-rm commented Dec 19, 2015

Just found that the same type of freeze happens with the actions:

  • "Copy to..."
  • "Move to..."

"Open URL With..." is ok.

As a result I have "Open with...", "Copy to...", and "Move to..." disabled.

QS no longer crashes when those actions are called on purpose (muscle memory) or incidently. QS is also now ~30% less valuable ;-)

I assume those three actions are all using the same lower level code that's causing the crash. Which fits since they all trigger the third pane that takes a path as input.

@mccoys
Copy link

mccoys commented Dec 30, 2015

I have the same issue here.

However, when I remove the ~/Desktop folder from the catalog, it works.

Hopefully that helps.

@ar-rm
Copy link
Author

ar-rm commented Jan 2, 2016

Hi,

tl;dr:

  • Fixed!
  • Problem was 2x aliases to .webloc files.
  • Then it got weird.
  • Then I found the underlying problem: Aliases to .webloc files that reference URLs with a : in the <title> tag (probably not just .webloc's).

@mccoys:
However, when I remove the ~/Desktop folder from the catalog, it works.
Hopefully that helps.

It did!

Given your success after removing the Desktop from the catalog, I took the opportunity to start from scratch and try to see if I could isolate the problem to something in the catalog.

Removing the Desktop didn't work for me. I wanted to go extreme, so I created a new user, setup QS and tested. Problem GONE. So the issue is definitely not tied to QS's codebase. So I went back to my main account and started to divide-and-conquer my way through my catalog.

Long story short I found the culprits: 2x aliases to .webloc files.

Here's where things get weird.

I assumed something must have gotten corrupted with those files and that's why it was giving QS trouble. I double clicked on the aliases in the Finder and they work! It's still linked to the originals and the URLs open in the default browser. I figure they must not be broken enough to give the Finder a problem, but they must be broken enough to give QS a problem. So I went to the URLs in Safari, created NEW .webloc files in a different folder (which I added to my QS "Custom" catalog) and created aliases to them.

Result: QS Crashed!

Weird right?

Then I tried going back into my test User Account, creating the .webloc's, making aliases, testing QS.

Result: QS Crashed!!

Just to make sure I wasn't going crazy, I excluded one from the QS catalog and QS still crashes (expected). I excluded the next and QS no longer crashed (expected).

IOW: The same URLs are responsible for crashing QS in two different users on the same machine.

(Another thing: I have plenty of .webloc and aliases to .webloc files in the QS catalog. There are even others in the same parent folder that's in my "Custom" catalog entry. None of them expose the bug.)


Observations:

  • This is a problem with the alias to the .webloc and not the original .webloc file. I can leave the originals in the QS catalog without them causing a crash.
  • As far as I can tell, there's nothing crazy about the file names that should be giving QS a hard time. In fact, I tested that. I renamed the original .webloc and the alias and it still crashed QS.
    • However one of the pages has a : (known disallowed filename character) and a / in the title, but the Finder converts those to - when the .webloc is made. The other page has neither.
    • So this shouldn't be the issue, right?
    • (Spoiler Alert: _Wrong!_ THIS IS the problem! See below.)
  • These .webloc's and aliases were created years ago on some previous version of the OS (10.6 or lower) and Safari. I'm recreating them on 10.9.5 and Safari 9.0.1 (9537.86.2.7.2).
  • I've tried the same test with different URLs and they were fine. No QS crash.
  • I can't say for sure if the content of those pages (specifically the titles) have changed since I first made the .webloc's and aliases. I'd suspect it hasn't. Archive.org shows some updates, but I haven't gone through all of them.

FOUND!

As I was proofreading this post, I thought of another test. I had a feeling this has something to do with that : or / in the file name. So what if I created my own html file, uploaded it to my server, and changed added the suspected characters (: / ,) to the filename? So I did:

  1. The <title> had only text to start. (The filename in the Finder is a product of the <title> tag.)
  2. I created a .webloc, created an alias from that, re-scanned the QS catalog and restarted QS a couple times.
  3. Result: OK.
  4. Added a / to the <title>, Repeated Step 2.
  5. Result: OK.
  6. Added a , to the <title>, Repeated Step 2.
  7. Result: OK.
  8. Added a : to the <title>, Repeated Step 2.
  9. Result: QS CRASH!

It would seem that even though the Finder converts the : to a -, something about that remains in the .webloc. That's passed along to the alias and that is what crashes QS. I can see how this makes perfect sense, since having a : in a filename is bad news. But I don't know the inner workings of QS enough to know where/why it's crashing. @skurfer: Hopefully I've provided enough info to track that down.

Still Unknown:
  • Why I wasn't able to recreate the crash, via my own test file, with a , in the <title> (Step 6 above)?
  • Maybe I didn't test right and a , in the filename doesn't cause a problem?

@mccoys: If you have the time, could you divide-and-conquer through the contents of your "Desktop" folder entry in the QS catalog, to see if you can find the culprit file in your case? It would be really helpful if we could figure out the commonality between the files that are giving QS a hard time. If I'm right about the : in the original file name, starting with that file (if any) should save you some time.

fyi: If anyone is going to test this by adding and removing crash-inducing files from your catalog, you'll need to quit QS each time you add/remove. In my tested, just rescanning the catalog didn't do the trick. Maybe there something I don't know, but I needed to: Check/Uncheck the box for that catalog item (in the drawer), Quit QS, Launch QS, and Test in order to get clean results.

Thanks for reading this far.
I hope this helps.

a.

@tiennou
Copy link
Member

tiennou commented Jan 25, 2016

I'm investigating that, thanks for the detailed report BTW. Hopefully I'll have a fix for it soon-ish. For the record, it's a deadlock between FSActions validIndirectObjects... and QSObject fileObjectWithPath: trying to do clipping-related stuff on the main thread, which is busy validating indirect objects 😏.

Trivia, : is one of those rare case where the whole UNIX-y underpinnings of OS X come crashing down, : is the real directory separator used on HFS+ volumes, which is why Finder absolutely hates them. The / is a lie, it's : all the way down !

@ar-rm
Copy link
Author

ar-rm commented Jan 29, 2016

I'm investigating that, thanks for the detailed report BTW.

Thanks for taking the time to read it!

Hopefully I'll have a fix for it soon-ish. For the record, it's a deadlock between FSActions validIndirectObjects... and QSObject fileObjectWithPath: trying to do clipping-related stuff on the main thread, which is busy validating indirect objects 😏.

That was number 1,322,457 on my "what it could be" list.

Trivia, : is one of those rare case where the whole UNIX-y underpinnings of OS X come crashing down, : is the real directory separator used on HFS+ volumes, which is why Finder absolutely hates them. The / is a lie, it's : all the way down !

Funny enough, I do think about that when I'm in the terminal, cd'ing around. Wasn't : used for paths in OS9 and below?

@tiennou
Copy link
Member

tiennou commented Jan 29, 2016

Wasn't : used for paths in OS9 and below?

Yep, it's been that way since the original HFS, 30 years ago, in System 2.1 (!), and : is the only reserved character. Even the Finder error message is as user-unfriendly as possible — I mean, reverting my newly created hard-to-solve-computer-science-problem name, really ? 😆

@ar-rm
Copy link
Author

ar-rm commented Jan 31, 2016

System 2.1 (!), and : is the only reserved character

That's cool. I didn't know that.

Even the Finder error message is as user-unfriendly as possible

Yeah. I love how it just throws out everything you entered because of a reserved character, instead of any of at least 5 more intuitive behaviors.

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

4 participants