Crash on startup (edge build)
Closed this issue · 18 comments
Using develop latest commit 0882237, The application crashes on startup for me.
I'm thinking you don't see the same issue or else you'd have found it already.
Basically, no matter what file I open, it crashes as soon as I:
- hover a row
- try to use the arrow keys to expand a row
- uncheck "Only non-translated"
I can't get a meaningful error message out of it though, just BAD_ACCESS.
I've tried:
- de.xliff, bigFile.xliff, and myFile.xliff
- Clean build
- System restart
- Setting an exception breakpoint (no further detail during the crash)
If I revert to d22642b I don't have this crash
@SimplGy in your stack trace, which objc method is called in frame 1?
Is each 0-12 item listed under "Thread 1" called a "frame"? Not being coy, this type of development is just new to me.
If so, the method is ViewController.outlineView(NSOutlineView, isGroupItem: Any) -> Bool
But on the right hand side it's just assembly:
I've had issues in the past with outlets not being ready when I try to use them (for instance, if a presenting VC tries to render because data is available, but the presented VC has not yet called viewWillAppear).
So, I tried making this an optional reference (and fixing all downstream errors that resulted), but got the same crashing behavior. This does not solve the problem, maybe that's useful to know:
@IBOutlet weak var outlineView: NSOutlineView?
could u try by 1.2 build here? https://github.com/remuslazar/osx-xliff-tool/releases/tag/1.2 it that works? I Also supplied a valid xliff file for testing.
That's commit 0882237, it's what I'm using. Also tried de.xliff and the new bigFile.xliff. Or do you mean I should use the binary you built?
@SimplGy yes, I mean the binary I just uploaded there
Same crash using your binary:
OS Version?
@SimplGy weird.. Sierra 10.12.1 here. Deployment Target is 10.10, though, so theoretically it should not be an issue.
@SimplGy regarding the implicitly unwrapped (!) optionals: AFAIK they are the same as strong optionals (?), so you can use constructs like myOutlet?.doSomething() for both types of optionals. Under the hood they are exactly the same thing, the ! does add some syntactic sugar to the code and make things clearer.
@SimplGy I am also not very familiar with lldb and debugging, but there are some really awesome WWDC sessions out there, e.g. https://developer.apple.com/videos/play/wwdc2016/417/. The section about low level debugging is really amazing! Check it out.
Re: !/?:
Sure thing! But if we're getting a bad access and I want to test if that's the cause, I wanted the compiler to help me track down all instances of implicit access.
Re: low-level debugging:
Thanks! I'll watch that with lunch today.
@SimplGy got ya! I thought you meant that in general it is safer to use strong optionals instead of implicitly unwrapped ones in such cases.
@SimplGy could u please test e5b1792, to see if that fixes the crash issue? I think, using value types is kinda problematic in older Swift runtimes for e.g. El Capitan. Also the NSOutlineView, being a quite old Cocoa API could have problems using value types.
I just created a "testing" branch for that purpose.
Sure, I'll check it tomorrow! +1 on the better search perf. Should be no problem searching 3000 or so nodes now :)
I am wondering about value types lately. We have some very strange and intermittent crashes in our iOS app that sort of point in that direction. Wonder if that's a root cause...