Freeze on "Open With..." action

[ar-rm]

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]

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

[ar-rm]

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]

Does this still happen with Quicksilver 1.3.4?

[ar-rm]

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]

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]

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]

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]

I have the same issue here.

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

Hopefully that helps.

[ar-rm]

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]

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]

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]

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]

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.