Signed app crashes on startup

[johansatge]

Hi,

a few users have reported that the sandboxed app crashes on startup.

The error occurs with the current 0.11.5 binary.

I built a new binary based on nwjs 0.12.1, but the problem remains for those users (same error).

(You can check the new binary here - I wanted to resolve this issue before submitting a pull request)

When the app is not signed, it runs smoothly.

---

Here is the error:

Crashed Thread:        0  CrBrowserMain  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000002, 0x0000000000000000

Complete log file is available here.

[johansatge]

Update: version 0.93 of @trevorlinton (available here) seems to have the same issue.

[alexeyst]

Hi @johansatge

Sorry for the delay. Does the empty app crash, or a specific line of code causes this? For me, the regular nw app works well and doesn't crash here, so I wanted to double check.

[johansatge]

Hi,

the empty app crashes too.

On my machine it works well, it does not make debugging easy..

[alexeyst]

I see. I believe it is important to get access to that machine somehow, are you able to ask the user to share screen with you to test?

[banezaklan]

Hello, I have this issue right now. I am sure I was able to start signed app at some point, but when I try today it is crashing. I tried with fixed 0.11.5 for Mac App Store, and with a regular one, same result.
I can start unsigned without problems, but when I sign it, it starts to crash with the same result as mentioned here, EXC_BREAKPOINT (SIGTRAP). Any ideas what to do about it?

[johansatge]

Hi,

@alexeyst I had access to the machine for a short time but I did not know where to start, as my knowledge of the patch (and more globally, the whole objective-c stuff) is quite limited..

@banezaklan if you can reproduce the issue, it should be easier to debug, I hope Alexey will know how to get you on track and find what's going on !

(If you want to download and install the tools needed to apply the patch and compile the project by yourself, the instructions on the nw.js docs are easy to follow)

[johansatge]

@patr0nus also uses a very similar patch for his app, maybe he ran into the same issue.

[banezaklan]

@johansatge Thanks! This is my error report, looks the same as what you have seen...

https://www.dropbox.com/s/vhmk1b4l6l9ssz3/nw-crash-log-osx.txt?dl=0

[banezaklan]

When I try to run signed app's node-webkit binary directly this is what I get:

[1828:0617/134020:ERROR:mach_broker_mac.mm(142)] bootstrap_look_up: Permission denied (1100)
[1828:0617/134020:ERROR:breakpad_mac.mm(238)] Breakpad initializaiton failed
[1827:0617/134027:FATAL:process_singleton_posix.cc(211)] Check failed: path.length() < arraysize(addr->sun_path). Socket path too long: /Users/bane/Library/Containers/com.a51.activecollab.timer/Data/Library/Application Support/activecollab-timer/S
** Unknown exception behavior: 0
[1] 1827 trace trap activecollab-timer\ 0-11-5\ signed.app/Contents/MacOS/node-webkit

Could it be that the full path is used in a "socket path" ? I think that if I shortened app ID it would work, but for users with longer user name, this would still happen?

[banezaklan]

Hmmm, looks like this problem goes down all the way to Chromium source.
https://code.google.com/p/chromium/issues/detail?id=469065

[alexeyst]

@banezaklan You got it, we need a shorter app ID. And I do think that this can happen with users with a longer name. For my app, I just have com.gcl.q to keep it short.

So, this brings us to an idea with @johansatge — can you get your app ID shorter and see if your users keep failing?

If that's it, we can look into fixing this together with NWjs team.

[banezaklan]

@alexeyst FYI, I just tried signing with a shorter app ID, com.a51.t and now I can start the app without problems. However, I created another user on my machine with a (really) long user name, and that made the string too long again:

[4865:0618/101154:FATAL:process_singleton_posix.cc(211)] Check failed: path.length() < arraysize(addr->sun_path). Socket path too long: /Users/branislav.zaklan.giga.mega.ultra.ludilo/Library/Containers/com.a51.t/Data/Library/Application Support/activecollab-timer/S

So, I think this confirms that even with shortening app ID it can still easily break for some users.

[johansatge]

Well done @banezaklan you got it...

So, this brings us to an idea with @johansatge — can you get your app ID shorter and see if your users keep failing?

I also tried this on my app. Shortened my bundle ID from 22 chars to 10 and sent the signed app to one of my users: it opened perfectly.

Someone has posted a fix on the chromium topic @banezaklan has mentionned.
I will try to work from it and recompile the app by the end of the week.

Cheers

(So bad the crashes are caused by this silly issue - I read somewhere that using a short bundle ID was recommended, but I thought it was a good practice, not a requirement !)

[johansatge]

Hi,

It looks good, @alexeyst I have sent a pull request with the updated binary.
The app runs seamlessly, regardless of the bundle ID length.

If you want to wait for the MAS confirmation, I'll upload my updated app tomorrow. I will keep you informed about the status.

In the meatine you may want to test the binary by yourselves @alexeyst @banezaklan.

[alexeyst]

Thank you @johansatge, great work!

Yep, would be great to have it confirmed by Apple, so if you have it with them it'd be ideal! I will also try the new binary with my app, and if it all works out it would be an insanely good upgrade—with new major version and fixes.

Thank you for spending your time on this!