Closed aequitas closed 9 years ago
ptsochantaris
commented
9 years ago Ah, thanks for reporting this - it seems Trailer is taking something for granted in the user record of the GE response that it's not getting! Will scan through that code and create quick build to see if it fixes this later on today.
If you can attach the crash report here, it would be of great help, thanks!
ptsochantaris
commented
9 years ago I just had a look and I don't think it's the user record, it may have something to do with the rate-limit headers... I think that the crash report will definitely pinpoint this and we can fix it quickly :+1:
aequitas
commented
9 years ago Process: Trailer [88448] Path: /Applications/Trailer.app/Contents/MacOS/Trailer Identifier: com.housetrip.Trailer Version: 1.3.1 (1212) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: Trailer [88448] User ID: 501
Date/Time: 2015-04-22 15:22:53.756 +0200 OS Version: Mac OS X 10.10.3 (14D131) Report Version: 11 Anonymous UUID: 8675CDD2-9923-C5C4-ECDE-7363AEF9949F
Sleep/Wake UUID: D35BBC01-6474-43E7-84C0-D8B99827FF9E
Time Awake Since Boot: 180000 seconds Time Since Wake: 22000 seconds
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000
Application Specific Information: fatal error: unexpectedly found nil while unwrapping an Optional value
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libswiftCore.dylib 0x000000011009493c _TTSf4s_s_d_d_TFSs18_fatalErrorMessageFTVSs12StaticStringS_S_SuT + 44 1 com.housetrip.Trailer 0x000000010feb62ab 0x10fdce000 + 950955 2 com.housetrip.Trailer 0x000000010feb94b1 0x10fdce000 + 963761 3 com.housetrip.Trailer 0x000000010fe9d107 0x10fdce000 + 848135 4 libdispatch.dylib 0x00007fff919eec13 _dispatch_client_callout + 8 5 libdispatch.dylib 0x00007fff919fc04e _dispatch_barrier_sync_f_slow_invoke + 412 6 libdispatch.dylib 0x00007fff919eec13 _dispatch_client_callout + 8 7 libdispatch.dylib 0x00007fff919facbf _dispatch_main_queue_callback_4CF + 861 8 com.apple.CoreFoundation 0x00007fff9031c3f9 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 9 9 com.apple.CoreFoundation 0x00007fff902d768f CFRunLoopRun + 2159 10 com.apple.CoreFoundation 0x00007fff902d6bd8 CFRunLoopRunSpecific + 296 11 com.apple.HIToolbox 0x00007fff8a15b56f RunCurrentEventLoopInMode + 235 12 com.apple.HIToolbox 0x00007fff8a15b2ea ReceiveNextEventCommon + 431 13 com.apple.HIToolbox 0x00007fff8a15b12b _BlockUntilNextEventMatchingListInModeWithFilter + 71 14 com.apple.AppKit 0x00007fff95cb99bb _DPSNextEvent + 978 15 com.apple.AppKit 0x00007fff95cb8f68 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346 16 com.apple.AppKit 0x00007fff95caebf3 -[NSApplication run] + 594 17 com.apple.AppKit 0x00007fff95c2b354 NSApplicationMain + 1832 18 com.housetrip.Trailer 0x000000010fdcf348 0x10fdce000 + 4936 19 libdyld.dylib 0x00007fff8f8335c9 start + 1
Thread 1:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x00007fff98428232 kevent64 + 10 1 libdispatch.dylib 0x00007fff919f1a6a _dispatch_mgr_thread + 52
Thread 2: 0 libsystem_kernel.dylib 0x00007fff9842794a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff8c42340d start_wqthread + 13
Thread 3: 0 libsystem_kernel.dylib 0x00007fff9842794a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff8c42340d start_wqthread + 13
Thread 4: 0 libsystem_kernel.dylib 0x00007fff9842794a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff8c42340d start_wqthread + 13
Thread 5: 0 libsystem_kernel.dylib 0x00007fff9842794a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff8c42340d start_wqthread + 13
Thread 6:: Dispatch queue: NSOperationQueue 0x60800022dc00 :: NSOperation 0x600000448280 (QOS: LEGACY) 0 libsystem_kernel.dylib 0x00007fff9842251a semaphore_wait_trap + 10 1 libsystem_platform.dylib 0x00007fff9196bc5b _os_semaphore_wait + 16 2 libdispatch.dylib 0x00007fff919f8557 _dispatch_barrier_sync_f_slow + 597 3 com.housetrip.Trailer 0x000000010feb8ce9 0x10fdce000 + 961769 4 com.housetrip.Trailer 0x000000010fe91233 0x10fdce000 + 799283 5 com.housetrip.Trailer 0x000000010fea4ec3 0x10fdce000 + 880323 6 com.housetrip.Trailer 0x000000010fe912d1 0x10fdce000 + 799441 7 com.housetrip.Trailer 0x000000010fea4ef3 0x10fdce000 + 880371 8 com.housetrip.Trailer 0x000000010fea4f5a 0x10fdce000 + 880474 9 com.apple.CFNetwork 0x00007fff96aefba2 49-[NSCFLocalSessionTask _task_onqueue_didFinish]_block_invoke + 157 10 com.apple.Foundation 0x00007fff94a5d7e8 NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK + 7 11 com.apple.Foundation 0x00007fff94a5d5b5 -[NSBlockOperation main] + 97 12 com.apple.Foundation 0x00007fff94a5ca6c -[__NSOperationInternal _start:] + 653 13 com.apple.Foundation 0x00007fff94a5c543 __NSOQSchedule_f + 184 14 libdispatch.dylib 0x00007fff919eec13 _dispatch_client_callout + 8 15 libdispatch.dylib 0x00007fff919f2365 _dispatch_queue_drain + 1100 16 libdispatch.dylib 0x00007fff919f3ecc _dispatch_queue_invoke + 202 17 libdispatch.dylib 0x00007fff919f16b7 _dispatch_root_queue_drain + 463 18 libdispatch.dylib 0x00007fff919fffe4 _dispatch_worker_thread3 + 91 19 libsystem_pthread.dylib 0x00007fff8c425637 _pthread_wqthread + 729 20 libsystem_pthread.dylib 0x00007fff8c42340d start_wqthread + 13
Thread 7:: com.apple.NSURLConnectionLoader 0 libsystem_kernel.dylib 0x00007fff984224de mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff9842164f mach_msg + 55 2 com.apple.CoreFoundation 0x00007fff902d7eb4 CFRunLoopServiceMachPort + 212 3 com.apple.CoreFoundation 0x00007fff902d737b __CFRunLoopRun + 1371 4 com.apple.CoreFoundation 0x00007fff902d6bd8 CFRunLoopRunSpecific + 296 5 com.apple.CFNetwork 0x00007fff96ab1220 +[NSURLConnection(Loader) _resourceLoadLoop:] + 434 6 com.apple.Foundation 0x00007fff94a41dc2 NSThreadmain + 1345 7 libsystem_pthread.dylib 0x00007fff8c425268 _pthread_body + 131 8 libsystem_pthread.dylib 0x00007fff8c4251e5 _pthread_start + 176 9 libsystem_pthread.dylib 0x00007fff8c42341d thread_start + 13
Thread 8: 0 libsystem_kernel.dylib 0x00007fff984224de mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff9842164f mach_msg + 55 2 com.apple.CoreFoundation 0x00007fff902d7eb4 CFRunLoopServiceMachPort + 212 3 com.apple.CoreFoundation 0x00007fff902d737b CFRunLoopRun + 1371 4 com.apple.CoreFoundation 0x00007fff902d6bd8 CFRunLoopRunSpecific + 296 5 com.apple.AppKit 0x00007fff95d8166b _NSEventThread + 137 6 libsystem_pthread.dylib 0x00007fff8c425268 _pthread_body + 131 7 libsystem_pthread.dylib 0x00007fff8c4251e5 _pthread_start + 176 8 libsystem_pthread.dylib 0x00007fff8c42341d thread_start + 13
Thread 9:: com.apple.CFSocket.private 0 libsystem_kernel.dylib 0x00007fff984273fa __select + 10 1 libsystem_pthread.dylib 0x00007fff8c425268 _pthread_body + 131 2 libsystem_pthread.dylib 0x00007fff8c4251e5 _pthread_start + 176 3 libsystem_pthread.dylib 0x00007fff8c42341d thread_start + 13
Thread 0 crashed with X86 Thread State (64-bit): rax: 0x00006000000ea200 rbx: 0x0000000115e70290 rcx: 0x0000000000000f9b rdx: 0x0000000000000f9a rdi: 0x00000001103de380 rsi: 0x0000000000000008 rbp: 0x00007fff4fe2fbc0 rsp: 0x00007fff4fe2fbb0 r8: 0x00007fff4fe2fb30 r9: 0x0000000000002200 r10: 0x00000000000057b8 r11: 0xfffffffffffb7990 r12: 0x0000000000000000 r13: 0x00007fff4fe30520 r14: 0x000000000000ba13 r15: 0x0000000000000000 rip: 0x000000011009493c rfl: 0x0000000000010202 cr2: 0x00000001160ca000
Logical CPU: 0 Error Code: 0x00000000 Trap Number: 6
Binary Images:
0x10fdce000 - 0x10fef5ff7 +com.housetrip.Trailer (1.3.1 - 1212)
External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 1 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 378169 thread_create: 0 thread_set_state: 0
VM Region Summary: ReadOnly portion of Libraries: Total=214.2M resident=115.2M(54%) swapped_out_or_unallocated=98.9M(46%) Writable regions: Total=88.3M written=5744K(6%) resident=12.0M(14%) swapped_out=8K(0%) unallocated=76.3M(86%)
REGION TYPE VIRTUAL =========== ======= CG backing stores 12K CG image 24K CG shared images 208K CoreAnimation 2276K CoreData Object IDs 4100K CoreImage 8K CoreUI image data 20K Foundation 4K Kernel Alloc Once 8K MALLOC 51.9M MALLOC (admin) 32K Memory Tag 242 12K Memory Tag 251 16K OpenCL 16K SQLite page cache 128K STACK GUARD 56.0M Stack 12.1M VM_ALLOCATE 17.2M DATA 18.5M IMAGE 528K LINKEDIT 73.1M TEXT 141.1M __UNICODE 552K mapped file 64.2M shared memory 4K =========== ======= TOTAL 442.0M
ptsochantaris
commented
9 years ago Excellent, thanks! I think I found it - it was what I suspected later on, your sever doesn't provide rate-limiting headers, and Trailer was expecting to find them for some reason. I've tweaked this now and attaching a build, can you check if it solves your issue?
[Hotfix is live now - link removed]
Brickster
commented
9 years ago I was having the same issue and the hotfix solved it for me.
ptsochantaris
commented
9 years ago Nice! Thanks for testing, will put out the hotfix in a bit :+1:
ptsochantaris
commented
9 years ago I also found a small issue with the Test button that @aequitas mentioned which should be fixed as well (not in the build above, but the one going out now).
aequitas
commented
9 years ago Trailer doesn't crash anymore, repositories are synced fine, the test button still gives the same error.
ptsochantaris
commented
9 years ago @aequitas Great! Now, about the test button, what it actually does is request an API usage update, so since your server doesn't support API usage, it gets a 400. The trick there is to find another way to test the server apart from that call. I'm adding it on the TODO list for 1.3.2 which should follow soon :+1:
The Hotfix version is up now, and includes some further fixes, so you probably want to run the auto-update once just in case. Thanks a lot of reporting this and testing.
aequitas
commented
9 years ago Great, thanks for the quick fix, one more thing, I notice there is a spinning load icon next to each open PR in the dropdown menu. No big deal, but it might be related.
ptsochantaris
commented
9 years ago No problem! The spinners are the place where people's avatars should appear - I assume the users on your server don't have avatars? Strange that the image loaders get "stuck" on the spinner instead of showing blank there, though, I'll check it out - do you get proper avatars on entries on the public GitHub?
aequitas
commented
9 years ago I seem to remember it worked with the previous version, but I need to check. We do have avatars on our server. Public Github avatars work just fine. I could also not find any logging related to avatars. If I have time I will dive into it.
ptsochantaris
commented
9 years ago Ah, interesting - yes please have a look and let me know, there really isn't any difference between how images for users are handled between GE and public Github, but I'm more than happy to provide you with a debug build with logging which tries to output the user records and URLs which it is trying to access so we can get a better idea about what's going on with that. Sorry I can't be more specific at this point but I don't have a GE server to play with over here :)
Let me know when or if you feel like testing more and I'll prep the build for you.
arudge
commented
9 years ago For what it's worth, I was having the same issue described when using GHE (constant crashing). I've since downloaded the latest build and things are back in working order. Thanks for the quick turn around!
ptsochantaris
commented
9 years ago Seems like my gut feeling was right and this wasn't just a small corner case, I'm glad I made that hotfix :+1:
Sorry for the regression guys, I simply did not do a proper beta test phase for 1.3.0, even though there had been refactoring in the syncing code, which has always caused regressions in the past. I'll try to be more conservative with what I put onto auto-update in the future.
aequitas
commented
9 years ago If you have a debug build i'd be happy to run it or if you need any help testing in the future with GE just let me know.
ptsochantaris
commented
9 years ago Hi @aequitas - thanks for offering to test it out! I'm attaching a debug build below which dumps out a lot of info about the data it's reading from the API, as well as the URLs of the avatars it is trying to load into the image views of the menu.
(Don't replace your existing build with this one, since the logging affects performance and memory use, you can run it from a separate directory, like in Downloads for instance. Apart from that it's identical to the latest 1.3.1 so it won't corrupt any data or cause any migration issues, just remember not to run this and your regular one at the same time)
Let it do a full sync, and then you can check out the log via Console.app.
There will be a lot of lines with DATA: <<.......>> which are the JSON responses from GitHub. See if you can fish out lines with "avatar_url" in them, and see what the URL for those is pointing to.
At the same time, the build will also tell you what URLs it is trying to load into the image views on the menu, see if you can spot the same URL being loaded there. If it looks like a proper URL, can you load the same URL in a web browser?
Also, on a related note, can you try the "Test" button and provide me with the DATA line that you get from that? I can use the error code from that line to improve that functionality for GE servers that don't support rate limiting.
Thanks again for your help, I hope I made some sense above -- if you have questions or need clarification please ask!
https://www.dropbox.com/s/yep857voxin4v2l/Trailer-Logging-Debug.zip?dl=0
aequitas
commented
9 years ago Hi @ptsochantaris,
for the avatar I get this in the logging:
23/04/15 11:29:47,556 Trailer[4638]: DATA: <<{"login":"johan-bloemberg","id":339,"avatar_url":"https://github.internal.example.com/avatars/u/339?","gravatar_id":"","url":"https://github.internal.example.com/api/v3/users/johan-bloemberg","html_url":"https://github.internal.example.com/johan-bloemberg","followers_url":"https://github.internal.example.com/api/v3/users/johan-bloemberg/followers","following_url":"https://github.internal.example.com/api/v3/users/johan-bloemberg/following{/other_user}","gists_url":"https://github.internal.example.com/api/v3/users/johan-bloemberg/gists{/gist_id}","starred_url":"https://github.internal.example.com/api/v3/users/johan-bloemberg/starred{/owner}{/repo}","subscriptions_url":"https://github.internal.example.com/api/v3/users/johan-bloemberg/subscriptions","organizations_url":"https://github.internal.example.com/api/v3/users/johan-bloemberg/orgs","repos_url":"https://github.internal.example.com/api/v3/users/johan-bloemberg/repos","events_url":"https://github.internal.example.com/api/v3/users/johan-bloemberg/events{/privacy}","received_events_url":"https://github.internal.example.com/api/v3/users/johan-bloemberg/received_events","type":"User","site_admin":false,"public_repos":0,"public_gists":0,"followers":0,"following":0,"created_at":"2014-08-01T07:12:05Z","updated_at":"2015-04-22T14:23:00Z","suspended_at":null,"private_gists":11,"total_private_repos":0,"owned_private_repos":0,"disk_usage":0,"collaborators":0}>>The 'avatar_url' works in the browser. But I do need to be authenticated, maybe that makes a difference?
Pressing the 'test' button doesn't result in any 'DATA', the only loglines are:
23/04/15 11:38:17,612 Trailer[4855]: (Company) Placing URL https:/github.internal.example.com/api/v3/rate_limit on the throttled list
23/04/15 11:38:17,613 Trailer[4855]: (Company) GET https:/github.internal.example.com/api/v3/rate_limit - FAILED: The operation couldn’t be completed. (Error response received error 404.)Let me know if there is anything more I can do.
ptsochantaris
commented
9 years ago Thanks for the feedback @aequitas - this is quite useful. The test button's result is specifically interesting, as I think I know what I need to tweak so you can try again (basically the 400 is being intercepted as an error by the networking layer and the message of the server is not reaching the layer that requested it)
As of the avatars, this may be a problem, since I'm not sure what kind of authentication would be required to fetch the image from that endpoint, will have to check GitHub's docs more.
I'll revert with another build later on today to help us investigate the Test issue more, and maybe I'll have a better idea on the authentication required for the image fetching - but unless we can use the token that you provide Trailer with somehow, I'm not sure if there are many options there apart from either moving the avatars to a public server like gravatar or just turning them off in the app. Will put up a good fight before I give up on it though, perhaps using headers like in the API calls...
Stay tuned!
ptsochantaris
commented
9 years ago Hi @aequitas and thanks for your patience - I'm attaching a build which should test the /user endpoint instead of the rate limit endpoint (I had used the rate limit one because it was theoretically a bit faster, but as we've discovered not all GitHub API servers support it) so it ought to work everywhere.
As for the avatars, I have a theory about adding auth headers to the avatar image requests, but that needs a bit of code, since for obvious security reasons those auth headers can't be added to any avatar request, only to those specifically going back to the API server. I will have a test build for that soon as well, if you still feel like trying it out.
In the meantime, "Test" should work fine here:
[link removed, updated build below]
aequitas
commented
9 years ago Hi @ptsochantaris, thx, i will give it a try when i'm in the office next week. I'm more than happy to do some more testing.
aequitas
commented
9 years ago Hi @ptsochantaris, I have tested it and it works agains as before. One thing I notice though when using it with GE (which I also noticed before). If you do not have the correct URL (http://company.github.com/ vs http://company.github.com/api/v3). It will tell both are OK, but only the latter will work.
ptsochantaris
commented
9 years ago Ah, good point, it's only checking the return code now, which is also valid on non-API end points. Will add some logic to check the actual user record returned and post a quick update here. I'll try to add some of the logic mentioned above for the avatars too, to see if it helps.
ptsochantaris
commented
9 years ago In the meantime, this should fix the test issue: [link removed, please use the updated build below]
aequitas
commented
9 years ago Works like a charm.
ptsochantaris
commented
9 years ago Great stuff :+1: Here is another build that tries to add auth headers to image requests, if and only if they come from the same host as the API server from which their related item came from. This is a bit of a shot in the dark, but an informed one based on your description of authorising to view the image URLs for the avatars - fingers crossed :)
The log messages will note if Trailer is adding extra auth headers onto each image request or not, so it may be worth having a look at Console.app to see if it's actually happening. Disclaimer: this code is totally untested, in case you get crashes please do attach a crash report, we may need to go through a build or two.
[link removed, please use the updated build below]
aequitas
commented
9 years ago I can see the auth headers being added:
29/04/15 09:27:12,386 Trailer[27211]: Image 'https://github.company.com/avatars/u/339?' comes from an owning API server, added auth headersBut unfortunately it has no effect, Avatar still is spinning loader.
If I get time today I will see if I can debug the request to see why it doesn't work and what might work with the GE server.
ptsochantaris
commented
9 years ago Oh well, it was worth a shot :( What's the result code of the image fetch by the way? Or is the server never replying?
In any case, yes please, if you can determine what kind of request will get the images across, we can definitely make it happen.
ptsochantaris
commented
9 years ago (also I assume github.company.com is you replacing the URL from the log for privacy reasons, it's not the original URL - if it is the original, that's the problem right there :))
jterhune
commented
9 years ago Thanks for working on this bug. I can curl any other /api/v3 endpoint with my oauth token, but the avatars endpoint results in a 302 redirect to the login page. We are on v2.1.6 of Github Enterprise.
Here's my heavily edited curl output:
% curl 'https://git.REDACTED.com/avatars/u/1976' -H "Authorization: REDACTED OAUTH_TOKEN" -v
> GET /avatars/u/1976 HTTP/1.1
>
< HTTP/1.1 302 Found
< Status: 302 Found
< Location: https://git.REDACTED.com/login?return_to=https%3A%2F%2Fgit.REDACTED.com%2Favatars%2Fu%2F1976
<html><body>You are being <a href="https://git.REDACTED.com/login?return_to=https%3A%2F%2Fgit.REDACTED.com%2Favatars%2Fu%2F1976">redirected</a>.</body></html>%I can get a 200 response using curl, but only if I include the user_session Cookie.
ptsochantaris
commented
9 years ago @jterhune Thanks for testing this, this is very useful info.
Trouble is, there is no straightforward way to fish or get the user_session cookie from your Github session into Trailer without some way on OS X that I can easily think of (ironically it's possible on iOS where Trailer uses an integrated web view, in fact most probably the shared NSURLSession there may work correctly after you log in from a webview? May need to check this)
I'll have to think a bit more about how this could work (suggestions are more than welcome of course!) but one thing that worried me is that, from what I understand, there is an infinite "loading" spinner going where the avatars were supposed to show in GE server lists, is that right? If so, the loading should at least "fail" once the 302 is received - this should be the immediate next step.
Have I understood correctly about the loader spinner never going away?
jterhune
commented
9 years ago I don't have any insights... seems like a bug with github enterprise to me. You're correct, the spinner never goes away.
ptsochantaris
commented
9 years ago I guess it's not quite a bug but a design constraint - I see there are options in GE that allow public avatars to be used rather than local ones, which should work fine in Trailer of course, but I'm going to keep digging into this. However, I'm not sure there will be any quick and easy solution to this issue very soon TBH.
I'm more than happy to get PRs and/or suggestions on how to improve or fix this ofcourse.
In the meantime, this debug build ought to correct the "infinite loading" problem, as there was a definite bug in that code. If you get the chance, give it a shot and let me know if it has improved that part at least:
[link removed, please used updated build below]
aequitas
commented
9 years ago Hi, @ptsochantaris, sorry for the late reply, I tried the latest build and it crashes on me a few seconds after start (with or without user interaction):
04/05/15 17:22:37,100 com.apple.xpc.launchd[1]: (com.housetrip.Trailer.7984[6995]) Service exited due to signal: Segmentation fault: 11Hi @aequitas - thanks for testing! I guess this means your copy is crashing when trying to sync. Is it possible you could attach the related crash report file to help track this down? You can usually find it attached to the log entry that reports the crash, or under the "System Diagnostic Reports" section in Console.app
aequitas
commented
9 years ago Process: Trailer [6995] Path: /Users/USER/Downloads/Trailer 3.app/Contents/MacOS/Trailer Identifier: com.housetrip.Trailer Version: 1.3.1 (1214) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: Trailer [6995] User ID: 501
Date/Time: 2015-05-04 17:22:36.652 +0200 OS Version: Mac OS X 10.10.3 (14D131) Report Version: 11 Anonymous UUID: 8675CDD2-9923-C5C4-ECDE-7363AEF9949F
Time Awake Since Boot: 7100 seconds
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000002
VM Regions Near 0x2: --> __TEXT 000000010a62a000-000000010a756000 [ 1200K] r-x/rwx SM=COW /Users/USER/Downloads/Trailer 3.app/Contents/MacOS/Trailer
Application Specific Information: objc_msgSend() selector name: respondsToSelector:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x00007fff947de0d7 objc_msgSend + 23 1 com.apple.CoreFoundation 0x00007fff93ec18e4 CFStringAppendFormatCore + 8180 2 com.apple.CoreFoundation 0x00007fff93fb73a0 _CFStringCreateWithFormatAndArgumentsAux2 + 256 3 com.apple.CoreFoundation 0x00007fff93fca77f _CFLogvEx2 + 127 4 com.apple.Foundation 0x00007fff986bfc47 NSLogv + 99 5 libswiftFoundation.dylib 0x000000010acbc1e7 _TF10Foundation5NSLogFtSSGSaPSs11CVarArgTypeT + 743 6 com.housetrip.Trailer 0x000000010a6cccef _TF7Trailer4DLogFTSSKT_GSqPSs11CVarArgTypeKT_GSqPS0_KT_GSqPS0_KT_GSqPS0___KT_GSqPS0T_ + 3359 7 com.housetrip.Trailer 0x000000010a6e7192 _TFC7Trailer3APIP33_CB516A4C354A4B217FC8D63920BD0B5911prWasMergedfS0_FTCS_11PullRequest8byUserIdCSo8NSNumberT + 786 8 com.housetrip.Trailer 0x000000010a710440 _TFFC7Trailer3APIP33_CB516A4C354A4B217FC8D63920BD0B5923investigatePrClosureForFS0_FTCS_11PullRequest8callbackFT_TT_U_FTGSqCSo17NSHTTPURLResponseGSqPSs9AnyObjectGSqCSo7NSErrorT + 1136 9 com.housetrip.Trailer 0x000000010a6f213c _TPATFFC7Trailer3APIP33_CB516A4C354A4B217FC8D63920BD0B5923investigatePrClosureForFS0_FTCS_11PullRequest8callbackFT_TT_U_FTGSqCSo17NSHTTPURLResponse_GSqPSs9AnyObjectGSqCSo7NSErrorT_ + 156 10 com.housetrip.Trailer 0x000000010a7194b1 _TTSf2n_n_d_i_nnTFFFC7Trailer3APIP33_CB516A4C354A4B217FC8D63920BD0B593getFS0_FTSS10fromServerCS_9ApiServer14ignoreLastSyncSb10parametersGSqGVSs10DictionarySSSS12extraHeadersGSqGS2_SSSS__10completionFT8responseGSqCSo17NSHTTPURLResponse_4dataGSqPSs9AnyObject5errorGSqCSo7NSErrorTT_U1_FTGSQCSo6NSData_GSQCSo13NSURLResponse_GSQS5_T_U_FTT + 161 11 com.housetrip.Trailer 0x000000010a6fc857 _TTRXFodTXFdCbdT + 39 12 libdispatch.dylib 0x00007fff9560cc13 _dispatch_client_callout + 8 13 libdispatch.dylib 0x00007fff9561a04e _dispatch_barrier_sync_f_slow_invoke + 412 14 libdispatch.dylib 0x00007fff9560cc13 _dispatch_client_callout + 8 15 libdispatch.dylib 0x00007fff95618cbf _dispatch_main_queue_callback_4CF + 861 16 com.apple.CoreFoundation 0x00007fff93f3a3f9 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 9 17 com.apple.CoreFoundation 0x00007fff93ef568f __CFRunLoopRun + 2159 18 com.apple.CoreFoundation 0x00007fff93ef4bd8 CFRunLoopRunSpecific + 296 19 com.apple.HIToolbox 0x00007fff8dd7956f RunCurrentEventLoopInMode + 235 20 com.apple.HIToolbox 0x00007fff8dd792ea ReceiveNextEventCommon + 431 21 com.apple.HIToolbox 0x00007fff8dd7912b _BlockUntilNextEventMatchingListInModeWithFilter + 71 22 com.apple.AppKit 0x00007fff998d79bb _DPSNextEvent + 978 23 com.apple.AppKit 0x00007fff998d6f68 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346 24 com.apple.AppKit 0x00007fff998ccbf3 -[NSApplication run] + 594 25 com.apple.AppKit 0x00007fff99849354 NSApplicationMain + 1832 26 com.housetrip.Trailer 0x000000010a62c6a8 main + 168 27 libdyld.dylib 0x00007fff934515c9 start + 1
Thread 1:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x00007fff9c046232 kevent64 + 10 1 libdispatch.dylib 0x00007fff9560fa6a _dispatch_mgr_thread + 52
Thread 2: 0 libsystem_kernel.dylib 0x00007fff9c04594a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff9004140d start_wqthread + 13
Thread 3: 0 libsystem_kernel.dylib 0x00007fff9c04594a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff9004140d start_wqthread + 13
Thread 4: 0 libsystem_kernel.dylib 0x00007fff9c04594a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff9004140d start_wqthread + 13
Thread 5:: Dispatch queue: NSOperationQueue 0x600000236980 :: NSOperation 0x600000255600 (QOS: LEGACY) 0 libsystem_kernel.dylib 0x00007fff9c04051a semaphore_wait_trap + 10 1 libsystem_platform.dylib 0x00007fff95589c5b _os_semaphore_wait + 16 2 libdispatch.dylib 0x00007fff95616557 _dispatch_barrier_sync_f_slow + 597 3 com.housetrip.Trailer 0x000000010a718cc9 _TFFC7Trailer3APIP33_CB516A4C354A4B217FC8D63920BD0B593getFS0_FTSS10fromServerCS_9ApiServer14ignoreLastSyncSb10parametersGSqGVSs10DictionarySSSS12extraHeadersGSqGS2_SSSS__10completionFT8responseGSqCSo17NSHTTPURLResponse_4dataGSqPSs9AnyObject5errorGSqCSo7NSErrorTT_U1_FTGSQCSo6NSData_GSQCSo13NSURLResponse_GSQS5T + 5929 4 com.housetrip.Trailer 0x000000010a6f074a _TPA__TFFC7Trailer3APIP33_CB516A4C354A4B217FC8D63920BD0B593getFS0_FTSS10fromServerCS_9ApiServer14ignoreLastSyncSb10parametersGSqGVSs10DictionarySSSS12extraHeadersGSqGS2_SSSS10completionFT8responseGSqCSo17NSHTTPURLResponse_4dataGSqPSs9AnyObject5errorGSqCSo7NSErrorT__T_U1_FTGSQCSo6NSData_GSQCSo13NSURLResponseGSQS5T_ + 298 5 com.housetrip.Trailer 0x000000010a7048a3 _TTRXFo_oGSQCSo6NSData_oGSQCSo13NSURLResponse_oGSQCSo7NSErrordTXFo_iTGSQSGSQS0GSQS1__iT + 51 6 com.housetrip.Trailer 0x000000010a6f07f1 _TPATTRXFo_oGSQCSo6NSData_oGSQCSo13NSURLResponse_oGSQCSo7NSErrordTXFo_iTGSQSGSQS0GSQS1__iT165 + 81 7 com.housetrip.Trailer 0x000000010a7048d3 _TTRXFo_iTGSQCSo6NSData_GSQCSo13NSURLResponse_GSQCSo7NSError_iTXFo_oGSQSoGSQS0oGSQS1_dT + 35 8 com.housetrip.Trailer 0x000000010a70493a _TTRXFo_oGSQCSo6NSData_oGSQCSo13NSURLResponse_oGSQCSo7NSErrordTXFdCb_dGSQSdGSQS0dGSQS1_dT + 90 9 com.apple.CFNetwork 0x00007fff9a70dba2 **49-[__NSCFLocalSessionTask _task_onqueue_didFinish]_block_invoke + 157 10 com.apple.Foundation 0x00007fff9867b7e8 NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK** + 7 11 com.apple.Foundation 0x00007fff9867b5b5 -[NSBlockOperation main] + 97 12 com.apple.Foundation 0x00007fff9867aa6c -[__NSOperationInternal _start:] + 653 13 com.apple.Foundation 0x00007fff9867a543 __NSOQSchedule_f + 184 14 libdispatch.dylib 0x00007fff9560cc13 _dispatch_client_callout + 8 15 libdispatch.dylib 0x00007fff95610365 _dispatch_queue_drain + 1100 16 libdispatch.dylib 0x00007fff95611ecc _dispatch_queue_invoke + 202 17 libdispatch.dylib 0x00007fff9560f6b7 _dispatch_root_queue_drain + 463 18 libdispatch.dylib 0x00007fff9561dfe4 _dispatch_worker_thread3 + 91 19 libsystem_pthread.dylib 0x00007fff90043637 _pthread_wqthread + 729 20 libsystem_pthread.dylib 0x00007fff9004140d start_wqthread + 13
Thread 6: 0 libsystem_kernel.dylib 0x00007fff9c04594a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff9004140d start_wqthread + 13
Thread 7:: com.apple.NSURLConnectionLoader 0 libsystem_kernel.dylib 0x00007fff9c0404de mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff9c03f64f mach_msg + 55 2 com.apple.CoreFoundation 0x00007fff93ef5eb4 CFRunLoopServiceMachPort + 212 3 com.apple.CoreFoundation 0x00007fff93ef537b __CFRunLoopRun + 1371 4 com.apple.CoreFoundation 0x00007fff93ef4bd8 CFRunLoopRunSpecific + 296 5 com.apple.CFNetwork 0x00007fff9a6cf220 +[NSURLConnection(Loader) _resourceLoadLoop:] + 434 6 com.apple.Foundation 0x00007fff9865fdc2 NSThreadmain + 1345 7 libsystem_pthread.dylib 0x00007fff90043268 _pthread_body + 131 8 libsystem_pthread.dylib 0x00007fff900431e5 _pthread_start + 176 9 libsystem_pthread.dylib 0x00007fff9004141d thread_start + 13
Thread 8: 0 libsystem_kernel.dylib 0x00007fff9c0404de mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff9c03f64f mach_msg + 55 2 com.apple.CoreFoundation 0x00007fff93ef5eb4 CFRunLoopServiceMachPort + 212 3 com.apple.CoreFoundation 0x00007fff93ef537b CFRunLoopRun + 1371 4 com.apple.CoreFoundation 0x00007fff93ef4bd8 CFRunLoopRunSpecific + 296 5 com.apple.AppKit 0x00007fff9999f66b _NSEventThread + 137 6 libsystem_pthread.dylib 0x00007fff90043268 _pthread_body + 131 7 libsystem_pthread.dylib 0x00007fff900431e5 _pthread_start + 176 8 libsystem_pthread.dylib 0x00007fff9004141d thread_start + 13
Thread 9:: com.apple.CFSocket.private 0 libsystem_kernel.dylib 0x00007fff9c0453fa __select + 10 1 libsystem_pthread.dylib 0x00007fff90043268 _pthread_body + 131 2 libsystem_pthread.dylib 0x00007fff900431e5 _pthread_start + 176 3 libsystem_pthread.dylib 0x00007fff9004141d thread_start + 13
Thread 10: 0 libsystem_kernel.dylib 0x00007fff9c04594a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff9004140d start_wqthread + 13
Thread 11: 0 libsystem_kernel.dylib 0x00007fff9c04594a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff9004140d start_wqthread + 13
Thread 12: 0 libsystem_kernel.dylib 0x00007fff9c04594a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff9004140d start_wqthread + 13
Thread 13: 0 libsystem_kernel.dylib 0x00007fff9c04594a __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff9004140d start_wqthread + 13
Thread 0 crashed with X86 Thread State (64-bit): rax: 0x00007fff9862b65f rbx: 0x00007fff555d21f7 rcx: 0x0000000000000000 rdx: 0x00007fff988d35fb rdi: 0x0000000000000002 rsi: 0x00007fff8e637256 rbp: 0x00007fff555d2030 rsp: 0x00007fff555d1ff8 r8: 0x00007fff555d21f7 r9: 0x00007fff555d2d62 r10: 0x0000000000000000 r11: 0x00007ffffffffff8 r12: 0x0000000000000002 r13: 0x0000000000000000 r14: 0x00007fff7d96ce80 r15: 0x000060800024cf30 rip: 0x00007fff947de0d7 rfl: 0x0000000000010246 cr2: 0x0000000000000002
Logical CPU: 2 Error Code: 0x00000004 Trap Number: 14
Binary Images:
0x10a62a000 - 0x10a755ff7 +com.housetrip.Trailer (1.3.1 - 1214) <0FE0DE4B-36EA-368D-8180-6A0037FC1C0A> /Users/USER/Downloads/Trailer 3.app/Contents/MacOS/Trailer
0x10a8d7000 - 0x10a906ff7 +org.andymatuschak.Sparkle (1.8.0 git - 1.8.0)
External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 1 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 3180 thread_create: 0 thread_set_state: 0
VM Region Summary: ReadOnly portion of Libraries: Total=215.4M resident=218.2M(101%) swapped_out_or_unallocated=16777216.0T(8167720747008%) Writable regions: Total=168.4M written=9124K(5%) resident=16.1M(10%) swapped_out=0K(0%) unallocated=152.4M(90%)
REGION TYPE VIRTUAL =========== ======= CG backing stores 4K CG image 20K CG shared images 176K CoreAnimation 2376K CoreData Object IDs 4100K CoreImage 8K CoreUI image data 12K Foundation 4K Kernel Alloc Once 8K MALLOC 129.9M MALLOC (admin) 32K Memory Tag 242 12K Memory Tag 251 8K OpenCL 16K SQLite page cache 128K STACK GUARD 56.1M Stack 14.2M VM_ALLOCATE 17.2M DATA 18.5M IMAGE 528K LINKEDIT 74.3M TEXT 141.1M __UNICODE 552K mapped file 67.3M shared memory 4K =========== ======= TOTAL 526.4M
ptsochantaris
commented
9 years ago Thanks! There was a problem with some debugging code related to another issue about merged items, hopefully this updated build should correct this:
https://www.dropbox.com/s/qs2m9sy4ky0lzz5/Trailer-avatars-and-merge-2.zip?dl=0
jterhune
commented
9 years ago I grabbed this latest build and its running fine for me -- no crashes or spinning avatars.
ptsochantaris
commented
9 years ago Ah, great, thanks for letting me know :+1: One more cleanup for the upcoming incremental update then. Shame we didn't find a straightforward way to get the actual avatars though... Will keep that on the long-term TODO list.
aequitas
commented
9 years ago Works fine for me to, no crashes, no spinning avatars
ptsochantaris
commented
9 years ago Great to have it confirmed :+1: Thanks for all your help with testing this @aequitas
ptsochantaris
commented
9 years ago Version 1.3.2 is up now and should include this fix. I will close this for now, but please feel free to re-open this in case there are issue or problems with it.
Working fine before, but since a few days Trailer crashes at launch when trying to access enterprise Github repository:
Removing application settings and configuring again results in this error when clicking 'test' for new API settings:
When only normal Github configured there are no errors.
If needed I can share the error report generated by OSX.
Edit: 1.2.2 seems to work fine. I tried 1.3.0 and 1.3.1 and both fail.