Hi,
I installed the latest and its not starting on my m1 macbook. It just sits there with a spinning globe and I have to force quit it.
The solutions I had opened previously re appear. I think I might be using the command line tools.
Cheers,
John
I am running the external compiler. 2769 Fire starts up ok with the newer tools.
I turned off the external compiler and then installed 2771. It starts up ok. If I then turn on the external compiler and restart the newer Fire that also starts up. I dont know what the issue was ?
Curious the “use external compiler” option (and indeed the external compiler itself, its version or presence) should have no effect on Fire at all, unless/until you hit Build and it checks whether to launch ebuild.exe from inside the app bundle or from a different path…
I don’t see how having the option checked would prevent Fire from launching successfully, and then unchecking it makes it launch, so something else must have gotten on there in between the steps that made a difference (or, it was just a one-time fluke of bad luck that something got stuck starting .2771 — which of course could still be an unrelated bug/deadlock).
very strange.
I’m downloading the server build of Fore 2771 right now, to test myself (I normally run locally built versions, of both external compiler and the IDE)
PS: i assume you can no longer reproduce this hang, now? if you can, or if it ever hangs like this again, can you launch Activity Monitor and run both a Spindump and a Sample Process for Fire, and send me the two results? 
Wow. Gatekeeper is confused today ;).
i download the fire .dmg, open it, it verifies, I double-click the app, it starts to veridy and says “cannot run app -1” while still verifying and then opening fine. Meanshoe Safari shows me this dialog while the .dmg is already long mounted and open… 
Long story short, though, Fire launched and opened the previously-open projects fine. :(.
So I don’t think there’s anything wrong with .2771 per see, but “just” something caused a one-time deadlock on launch there for you (which h ofc id love to narrow down and fix, but… ;).
I think I got lucky and was able to get it to do it again
Sample of Fire.zip (28.6 KB)
Spindump.zip (412.1 KB)
Thanx. this one is probably the culprit. though I’m not sure why/how it locks up, this remote execution should probably be delayed until its needed and nor run on launch. Will fix for vNext
1001 -[__RemObjects_Elements_Basics_ElementsPaths LoadPaths] + 4412 (Fire + 1335512) [0x1048ba0d8]
1001 _objc_msgSend_uncached + 68 (libobjc.A.dylib + 30948) [0x1853828e4]
1001 lookUpImpOrForward + 1052 (libobjc.A.dylib + 32744) [0x185382fe8]
1001 initializeAndMaybeRelock(objc_class*, objc_object*, mutex_tt<false>&, bool) + 184 (libobjc.A.dylib + 33360) [0x185383250]
1001 initializeNonMetaClass + 608 (libobjc.A.dylib + 34864) [0x185383830]
1001 CALLING_SOME_+initialize_METHOD + 24 (libobjc.A.dylib + 35812) [0x185383be4]
1001 +[__RemObjects_Elements_Basics_ConcreteNuGetPackage initialize].1 + 444 (Fire + 1679352) [0x10490dff8]
1001 -[__RemObjects_Elements_Basics_EchoesPaths DotNetArchitecture] + 220 (Fire + 1291168) [0x1048af3a0]
1001 -[__RemObjects_Elements_Basics_EchoesPaths GetDotNetArchitecture] + 588 (Fire + 1248264) [0x1048a4c08]
1001 +[__RemObjects_Elements_RTL_Process Run::::::@SNRN30RemObjects.Elements.RTL.StringRGN37RemObjects.Elements.RTL.ImmutableList0RN30RemObjects.Elements.RTL.StringRGN43RemObjects.Elements.RTL.ImmutableDictionary0RN30RemObjects.Elements.RTL.StringRN30RemObjects.Elements.RTL.StringN49RemObjects.Elements.RTL.ImmutableStringDictionaryRN30RemObjects.Elements.RTL.StringBRN30RemObjects.Elements.RTL.StringBRN30RemObjects.Elements.RTL.String] + 756 (Fire + 7719964) [0x104ed0c1c]
1001 -[NSConcreteTask waitUntilExit] + 332 (Foundation + 1008348) [0x18653e2dc]
1 Like
Funny thing is, this has to be a compiler bug, as nothing in this path calls the property that executes this task.
SO we have a three-for-one: I actually improved the property from being a plain reader to lazy (which works around the bug, and is better/cleaner), and we gotta fix the actual compiler bug that caused it to be called and an IE I found while trying to reproduce the bug in a standalone test case ;).
Either way, as fas as Fire is concerned its fixed. Please let me kn ow if the issue is severe/often enough for you to need a new build before Friday.
Meanwhile, I’ve downgraded .2771 not Preview channel, sincere don’t know how many others will be how likely to be affect day this dead-lock (the deadlock itself which still doesn’t make full sense to me).
1 Like
Build for 20220912-131824-fire-develop [setups] started on gazorpazorp
should have the fix
1 Like