x/mobile: iOS framework build with GO randomly hang on iOS

[bestbug456]

What version of Go are you using (go version)?

$ go version
1.19.4

Does this issue reproduce with the latest release?

At the moment is not possible to verify with the latest version of GO.

What operating system and processor architecture are you using (go env)?

The problem appear randomly on ios (GOOS=ios GOARCH=arm64)

What did you do?

We recived a crash report about a thread having a EXC_BAD_ACCESS on iOS, we are not able to reproduce the crash on our laboratory but after several test we think this behaviour is not cause by the frameworks itself rather than some other problem inside the GO stack that we are not able to figure out. The stacktrace report the following information:

Exception Type:  EXC_BAD_ACCESS (SIGABRT)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000038
Exception Codes: 0x0000000000000001, 0x0000000000000038
VM Region Info: 0x38 is not in any region.  Bytes before following region: 68719476680
      REGION TYPE                 START - END      [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  
      commpage (reserved)     1000000000-7000000000 [384.0G] ---/--- SM=NUL  ...(unallocated)
Triggered by Thread:  2

Thread 2 Crashed:
0   libsystem_kernel.dylib        	0x00000001c95c2558 __pthread_kill + 8 (:-1)
1   libsystem_pthread.dylib       	0x00000001ea403118 pthread_kill + 268 (pthread.c:1670)
2   libsystem_c.dylib             	0x0000000191ba754c raise + 32 (raise.c:30)
3   libname                  	        0x00000001064b44c4 _cgo_topofstack + 5092
4   libname                  	        0x00000001064b2fd8 CMAC_resume + 501884

All our stacktrace are identical to this one, all try to access to 0x0000000000000038 and all have the same instruction on the thread. The same device does not always have the crash, make it even harder to track.

What did you expect to see?

No crash or some information related to our library

What did you see instead?

Randomly application crash on our userbase

[dr2chase]

@hyangah
@golang/runtime

[bestbug456]

Hello,
Can someone help us? The number of crash is increasing, it's look like something related to iOS 16.5 and above.

Thanks

[cherrymui]

Could you share more information about your code and the failure? How deos your code make cgo calls? Is the failure persistent or sporadic? Could you try building it with newer version of Go, Go 1.21.0? Thanks.

0 libsystem_kernel.dylib 0x00000001c95c2558 __pthread_kill + 8 (:-1)
1 libsystem_pthread.dylib 0x00000001ea403118 pthread_kill + 268 (pthread.c:1670)
2 libsystem_c.dylib 0x0000000191ba754c raise + 32 (raise.c:30)

This looks like the program (the Go runtime, or not) intentionally crashing when it is already in a bad condition, like receiving an unhandled signal on a non-Go thread.

[bestbug456]

Hello cherrymui, thanks for the support:

Could you share more information about your code and the failure?

Yes if you can narrow this request I can try to share more information about it

How deos your code make cgo calls?

Can you narrow you request? Because I don't get it what you are looking for. Thanks!

Is the failure persistent or sporadic?

the problem is not persistent (same user lunching the application again does not have the crash). But the same user may have the same crash again

Could you try building it with newer version of Go, Go 1.21.0?

This is more difficult to do before end of September

This looks like the program (the Go runtime, or not) intentionally crashing when it is already in a bad condition, like receiving an unhandled signal on a non-Go thread.

So this mean that the GO is intercepting some system signal generated from other part of the application? Can you give to me some more information about this theory? Also, can this behavior be changed somehow?

[bestbug456]

Hello @cherrymui do you had the time to view my previus response? Can you give to me a feedback about it?
Thanks!