Integration & Contract Tests are failing on MacOS after go upgrade 1.20

[ajayesivan]

Integration & Contract Tests are failing on MacOS after upgrading to Go version 1.20. This issue is only reproducible on MacOS; tests work fine on NixOS.

The issue was introduced by: #19564

Error:

/private/tmp/tmp-status-mobile-6d6766dce1/nix-shell-92776-0/rc: line 3: 93011 Abort trap: 6           node --require ./test-resources/override.js "$SHADOW_OUTPUT_TO"
make: *** [_test-clojure] Error 134

It would be nice to implement a MacOS CI pipeline to catch such issues in the future.

cc: @siddarthkay

[siddarthkay]

Indeed the failure is due to upgrading golang to 1.20.12

One key thing worth noting is that when I update my overlay.nix to point go and buildGoModule to 1_19 Integration tests start working on MacOS.

This weird failure of contract tests with golang version 1.20 happens only on MacOS which is very annoying and we know this does not happen on Linux else it would also be reproducible on CI hosts.

[siddarthkay]

The key error message to focus on from the stack trace is this

dyld[30877]: missing symbol called

and this happens right after

2024-05-08T14:02:24.489Z DEBUG [utils.re-frame:25] - Handling re-frame event:  :wallet/get-wallet-token

My initial guess was that :wallet/get-wallet-token triggers the failure.

I then commented out this reframe event and that the contract tests would run for longer but eventually fail with the same error message, so :wallet/get-wallet-token reframe event was not the root cause.

[siddarthkay]

dyld[70658]: missing symbol called typically indicates a problem with dynamic linking in a macOS application.

dyld stands for "dynamic linker/loader". It is the component of the macOS operating system responsible for loading and linking dynamic libraries required by an application at runtime.

So at some point in the test run a "symbol" is not found. If we know which symbol is not found that would help us to narrow down the root cause further.

[siddarthkay]

I assume that the source of missing symbols for integration tests could be status.cpp file located here -> https://github.com/status-im/status-mobile/blob/497c95fd2682653472722f7fcc13ec74e244318e/modules/react-native-status/nodejs/status.cpp

I tried to regenerate this file by using this tool https://github.com/divan/go2nodebinding/tree/master on https://github.com/status-im/status-go/blob/6b5315b1fde8edfd7268eaef41af3ea24412f644/mobile/status.go

But the file contained fewer functions than what we already have.. it could be possible that this file was later on modified by hand rather than being auto generated.

Perhaps @cammellos can assist more since he seems to have some experience with this file.
Maybe @qfrank as well.
Would love to see if we can add some debug statements in this cpp file or in the integration test mechanism itself to figure out why its failing this way and only on MacOS.

[siddarthkay]

aha

status-mobile/binding.gyp

Line 12 in 497c95f

"MACOSX_DEPLOYMENT_TARGET": "10.7"

could be interesting

[siddarthkay]

As per golang 1.20 changelog : https://go.dev/doc/go1.20#darwin

Go 1.20 is the last release that will run on macOS 10.13 High Sierra or 10.14 Mojave. Go 1.21 will require macOS 10.15 Catalina or later.

[siddarthkay]

I tried this change in status-mobile/binding.gyp

diff --git a/binding.gyp b/binding.gyp
index f161b3299..a0419d0ba 100644
--- a/binding.gyp
+++ b/binding.gyp
@@ -8,9 +8,6 @@
     "sources": [
       "./modules/react-native-status/nodejs/status.cpp"
     ],
-    "xcode_settings": {
-      "MACOSX_DEPLOYMENT_TARGET": "10.7"
-    },
     "libraries": [
       "<!(pwd)/result/libstatus.a"
     ],
@@ -21,7 +18,13 @@
           "-framework CoreFoundation",
           "-framework CoreServices",
           "-framework Security"
-        ]
+        ],
+        "xcode_settings": {
+           "GCC_ENABLE_CPP_EXCEPTIONS": "YES",
+           "GCC_ENABLE_CPP_RTTI": "YES",
+           "MACOSX_DEPLOYMENT_TARGET": "11.0",
+           "CLANG_CXX_LANGUAGE_STANDARD": "c++20"
+        },
       }]
     ]
   }, {

but the error is still reproducible and I do not get any additional information on the exception.

[qfrank]

it could be possible that this file was later on modified by hand rather than being auto generated.

well guessed, I just noticed that comment "DO NOT EDIT:..." , have you tried re-generate? @siddarthkay

[siddarthkay]

have you tried re-generate?

yes I did and the generated file was quite small and missed many functions.
After speaking with @cammellos : I found out that we have long abandoned that tool and we edit this file manually.

I will remove this comment in my next PR.