Can't launch Status app on Intel-based Mac #15134
Comments
|
we need to get someone with Intel chip on mac to debug what is going on |
|
Tried to reproduce on M1 Pro:
|
|
I was able to reproduce this crash on the app start (got exactly the same stacktrace), it has nothing with the specific Status data folder the app crashes because of the changed Go version. It has something with CGo bindings. rc2.29 commit Also if I change just the local Go version to 1.21 and try the same commit, getting this: At this moment I am not pretty sure how to make it work on Mac Intel, maybe somebody more experienced in this field may help, otherwise I will most likely need much more time till I figure it out. |
@saledjenic just to make it clear, this is on Intel mac only, right? |
This |
|
cc @siddarthkay |
Correct.
This is what I see when I try to run the rc2.29 commit The commit after it introduces the official changes that we did to switch to Go1.21, when I run it then I see the same stacktrace as in desktop_rc11.log posted in the description of this issue. |
|
|
@siddarthkay do you think it's possible to fix it or we should revert the upgrade to 1.21 for now? |
|
@jrainville : I plan to do some investigations tomorrow and find the root cause of crash, if it is indeed related to go upgrade then the proper fix would most likely be additional build flags. |
siddarthkay
changed the title
|
The core error message worth investigating is this : There is indeed an issue in go repo for this : Other possibly related issues : |
|
@siddarthkay Your magic binary worked for me |
siddarthkay
moved this from Iteration Backlog
to In Progress
in Status Desktop/Mobile Board
|
Hmmmm, @siddarthkay :( So I've tried to open the Desktop app again today and it is crashing before even loading. I haven't changed anything. |
|
@Samyoul : Thanks for the report, this was also reported on the PR here #15194 (comment) |
anastasiyaig
changed the title
|
Now that I have access to an x86_64 MacOS Host I've Investigated a bit further. The crash happens in this function in status-go : stacktrace -> Next steps would be to narrow down which line of code triggers this crash by pointing to a branch in status-go and decorating it with logs. |
|
You can run |
|
According to the stacktrace //export KeycardInitFlow
func KeycardInitFlow(storageDir *C.char) *C.char {
var err error
globalFlow, err = skg.NewFlow(C.GoString(storageDir))
return retErr(err)
}This makes sense for errors like this : To confirm my suspicion, I will add logs to |
|
After I commented out calls to 
|
|
cc @saledjenic @igor-sirotin ^ |
|
@bitgamma please check this comment and let us know what you think? |
|
For what its worth : I have a branch at |
|
@saledjenic I don't think it is the same problem since it was something with signal handling. SIGSEGV seems like something is trying to access a null pointer. Might it be that storageDir is not passed correctly or is still null when the function is invoked? |
|
Okay I was able to get the crash to go away for So most likely on will resume tomorrow |
According to my logs StorageDir was set but the resulting path did not exist : |
|
and for some reason this code path does not crash on arm64 macOS but only on amd64. |
|
The issue is indeed some weird quirk of go for darwin amd64, but I would not spend more time in getting those issues fixed, they would indeed be fixed in go 1.24 or something even further. For now I think this solution is good enough. diff --git a/src/app_service/service/keycard/service.nim b/src/app_service/service/keycard/service.nim
index 1d023d6ba2c..fd9ec993c9c 100644
--- a/src/app_service/service/keycard/service.nim
+++ b/src/app_service/service/keycard/service.nim
@@ -97,9 +97,13 @@ QtObject:
proc init*(self: Service) =
if self.doLogging:
debug "init keycard using ", pairingsJson=status_const.KEYCARDPAIRINGDATAFILE
- let initResp = keycard_go.keycardInitFlow(status_const.KEYCARDPAIRINGDATAFILE)
- if self.doLogging:
- debug "initialization response: ", initResp
+ # This code must not be executed on Darwin amd64
+ # since go 1.21 Intel macs are not able to handle nil cStrings from go
+ # resulting in bad flushGen 12 in prepareForSweep; sweepgen 0
+ if not (status_const.IS_MACOS and status_const.IS_INTEL):
+ let initResp = keycard_go.keycardInitFlow(status_const.KEYCARDPAIRINGDATAFILE)
+ if self.doLogging:
+ debug "initialization response: ", initResp
proc processSignal(self: Service, signal: string) =
var jsonSignal: JsonNode
@@ -174,10 +178,14 @@ QtObject:
proc cancelCurrentFlow*(self: Service) =
if self.busy:
return
- let response = keycard_go.keycardCancelFlow()
- self.currentFlow = KCSFlowType.NoFlow
- if self.doLogging:
- debug "keycardCancelFlow", kcServiceCurrFlow=($self.currentFlow), response=response
+ # This code must not be executed on Darwin amd64
+ # since go 1.21 Intel macs are not able to handle nil cStrings from go
+ # resulting in bad flushGen 12 in prepareForSweep; sweepgen 0
+ if not (status_const.IS_MACOS and status_const.IS_INTEL):
+ let response = keycard_go.keycardCancelFlow()
+ self.currentFlow = KCSFlowType.NoFlow
+ if self.doLogging:
+ debug "keycardCancelFlow", kcServiceCurrFlow=($self.currentFlow), response=response
##########################################################
## Used in test env only, for testing keycard flows
@@ -488,4 +496,4 @@ QtObject:
error "registerForKeycardAvailability can be called only when keycard is busy"
return
self.registeredCallback = p
- self.runTimer(CheckKeycardAvailabilityInterval, $TimerReason.WaitForKeycardAvailability)
\ No newline at end of file
+ self.runTimer(CheckKeycardAvailabilityInterval, $TimerReason.WaitForKeycardAvailability)
diff --git a/src/constants.nim b/src/constants.nim
index b6beddd9ae1..aa7eaadaa50 100644
--- a/src/constants.nim
+++ b/src/constants.nim
@@ -3,6 +3,7 @@ include env_cli_vars
## Added a constant here cause it's easier to check the app how it behaves
## on other platform if we just change the value here
const IS_MACOS* = defined(macosx)
+const IS_INTEL* = defined(amd64)
# For future supporting fingerprints on other platforms
const SUPPORTS_FINGERPRINT* = IS_MACOS
# This is changed during compilation by reading the VERSION file |
|
I've tried to make a minimal crash reproduction here https://github.com/siddarthkay/status-desktop-intel-crash-reproducer Thank you |
|
another discovery worth mentioning is that after enabling debug symbols I see |
|
I did find a status-go test which calls Same test on intel MacOS fails : |
|
I found yet another solution to the crash problem. For me crashes went away after I introduced minor sleep time before calling status-go methods that would crash. I've limited the sleep code only to Intel MacOS to avoid any slowdowns on arm MacOS. ref -> 492d73e I think this would solution is definitely better than commenting our or skipping any keycard flows. |
I think it can be a good stop gap until we find a better solution. My only concert is if that 300ms is enough for all machines. I assume this is a race condition, so we need to be sure that it's not on the edge where some people will crash |
|
@jrainville you're right. I intend to play with this number further. When testing with @qoqobolo she was able to reproduce the crash once but then it worked for her afterwards. Maybe 500 milliseconds is a good safety measure. Will continue tomorrow 👋 |
|
@siddarthkay we plan on cutting the release branch soon. We can always add your fix to the release branch afterwards, but I just wanted to check if maybe there was a stop gap we could merge for now? |
|
@jrainville : I think a good enough solution for now would be to check and merge the sleep solution in this PR -> #15194 and we should then open another issue to further investigate the race conditions on intel MacOS. |
github-project-automation
bot
moved this from Code Review
to Done
in Status Desktop/Mobile Board
Bug Report
Description
Starting with RC 10 https://github.com/status-im/status-desktop/releases/tag/2.29.0-rc.10 I started experiencing a crash when launching the Status app.
The app crashes even before opening the login screen.
Screen.Recording.2024-06-11.at.11.12.20.mov
Logs:
desktop_rc11.log
I first faced this when I tried to open a build with my main user (community status member). Then I tried to install yesterday’s nightly and run it with another test user, who also had contacts and community.
The app crashed in both cases.
Then I tried deleting the data folder and launching the application.
The first 5 attempts the crash repeated, but then I was able to launch the app (without changing anything) and create a user.
After that, I could no longer log in to it.
Also, after creating another new user, I tried to open the QR code to sync with a mobile device, but I got a crash when opening the QR code. Here are the logs for this case:
My macOS updated yesterday to Sonoma 14.5, maybe this could be the reason? Or I am doing something wrong.
We couldn't reproduce this on any other Mac.
Additional Information
The text was updated successfully, but these errors were encountered: