Closed phpcodemonkey closed 7 years ago
Finding out if this is an upstream problem, it really sounds like one ...
What is "ToDoist application"? Is it running in the same process?
I assume this: https://en.todoist.com/
Yes that's right, specifically, the Mac version https://en.todoist.com/mac
And it is running as a separate process?
I would hope/assume so, given that it's an App Store app!
Definitely curious. Can you see if it happens with regular libui (not PHP)?
@andlabs Yes, just ran make examples in libui, then ran controlgallery, cpp-multithread & histogram with ToDoist - exact same behaviour. So that confirms it's related to upstream libui after all.
For reference, this is compiled with the latest master of libui.
It's either libui or todoist, and I'm hoping it's the former...
Actually wait, how are you running the libui programs? Are you running them through Finder, or through Xcode, or through the command line? Are they a .app bundle, or a bare executable? I might have an idea as to what's going on, but I'm not sure whether libui is breaking a rule or Todoist is making an assumption.
And does Todoist have a feature where it watches for apps being launched?
Actually forget that, whatever the answer is, the bug is actually in Todoist:
https://developer.apple.com/reference/appkit/nsrunningapplication/1535500-bundleurl?language=objc
The bundleURL
property of a NSRunningApplication is allowed to be nil
. Todoist is assuming it can never be nil
, and is thus crashing because libui programs that are not run in .app bundles have no bundle URL.
So this will have to be reported to them.
Ok thanks, at least that's a good find! For completeness, I was running libui apps from the command line as bare executables.
Yep, so that lines up with what I found. Thanks!
(This is the only other place with a similar stack trace. The issue there probably isn't the same, but I might as well give credit to what helped me figure this out.)
And for what it's worth, libui would not be the only thing that would cause Todoist to crash; it just happens to be the first thing found to make it crash. This would make it crash too. I'm sure short scripts in things like Python or Ruby could be written but I lack the time to actually do so right now.
I'm going to close the bug because there is nothing that I, or @andlabs can do now.
@phpcodemonkey feel free to (please do) update this thread with whatever you find when you report upstream.
Thanks @krakjoe @andlabs! Reported upstream, fingers crossed!
From ToDoist:
Our developer believes that this is an issue that might have been addressed in version 6.3.17. Can you please let us know if the issue still persists for you even with that version?
And it is solved :)
Cool :D
In initial testing with php-ui, there's a repeatable issue observable when any php-ui window is first brought into focus - it causes ToDoist application to generate an "Internal Error - An uncaught exception was raised" with a stack trace, ToDoist can "Continue", however, I'm never sure that's a wise move. This issue presents whether ToDoist was running before the php process or not, they just both have to be running and the php-ui window gain focus (click or alt-tab display the problem, e.g. simply gaining focus).
The source of this could be upstream in libui itself of course or ToDoist (a usually stable app v6.3.16 (Build 10640)), however, I would have thought things shouldn't be crossing over like this.
Example ToDoist stack trace at https://gist.github.com/phpcodemonkey/c645758b0296860fef0daed2db010f32