http request memory corruption crash during SSL handshake

[WillCalderwood]

Issue details

Intermittent crash during the SSL handshake. I've never managed to reproduce this, but get lots of reports in crashlytics. If anyone has any idea of what could be going on or how I should proceed then please let me know.

Reproduction steps/code

Currently unable to reproduce

Configuration

Build Tools:

• [x] IDEA plugin
• [X] Gradle plugin

Versions:

• Gdx version: 1.9.13
• Robovm: 2.3.13 (Also seen in earlier versions)
• XCode: 12.4
• JDK: 1.8.0 201

Build Targets:

Multiple iSO devices. No specific pattern noticed

---

Stacktrace

SIGABRT ABORT 0x00000001aefda414

Crashed: Thread
0  libsystem_kernel.dylib         0x1aefda414 __pthread_kill + 8
1  libsystem_pthread.dylib        0x1ccb34b50 pthread_kill + 272
2  libsystem_c.dylib              0x18a4b3b74 abort + 104
3  libsystem_malloc.dylib         0x190e9149c _malloc_put + 558
4  libsystem_malloc.dylib         0x190e9167c malloc_report + 64
5  libsystem_malloc.dylib         0x190e85f68 free + 532
6  IOSLauncher                    0x1028a767c CRYPTO_free + 4340315772
7  IOSLauncher                    0x1028ea444 ssl_parse_serverhello_tlsext + 4340589636
8  IOSLauncher                    0x1028d32ec ssl3_get_server_hello + 4340495084
9  IOSLauncher                    0x1028d2754 ssl3_connect + 4340492116
10 IOSLauncher                    0x10274ece8 Java_com_android_org_conscrypt_NativeCrypto_SSL_1do_1handshake + 4338904296
11 IOSLauncher                    0x102a6eae0 [J]com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(JLjava/io/FileDescriptor;Lcom/android/org/conscrypt/NativeCrypto$SSLHandshakeCallbacks;IZ[B[B)J + 982872
12 IOSLauncher                    0x102a658d4 [j]com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(JLjava/io/FileDescriptor;Lcom/android/org/conscrypt/NativeCrypto$SSLHandshakeCallbacks;IZ[B[B)J[clinit] + 945484
13 IOSLauncher                    0x102a8f7cc [J]com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake()V + 405 (OpenSSLSocketImpl.java:405)
14 IOSLauncher                    0x102a8e30c [j]com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake()V[synchronized] + 1111940
15 IOSLauncher                    0x10297f9a8 [J]com.android.okhttp.Connection.upgradeToTls(Lcom/android/okhttp/TunnelRequest;)V + 149 (Connection.java:149)
16 IOSLauncher                    0x10297f6d8 [J]com.android.okhttp.Connection.connect(IILcom/android/okhttp/TunnelRequest;)V + 111 (Connection.java:111)
17 IOSLauncher                    0x102998e9c [J]com.android.okhttp.internal.http.HttpEngine.connect()V + 295 (HttpEngine.java:295)
18 IOSLauncher                    0x102998b3c [J]com.android.okhttp.internal.http.HttpEngine.sendSocketRequest()V + 258 (HttpEngine.java:258)
19 IOSLauncher                    0x102998888 [J]com.android.okhttp.internal.http.HttpEngine.sendRequest()V + 206 (HttpEngine.java:206)
20 IOSLauncher                    0x10299dafc [J]com.android.okhttp.internal.http.HttpURLConnectionImpl.execute(Z)Z + 346 (HttpURLConnectionImpl.java:346)
21 IOSLauncher                    0x10299c7bc [J]com.android.okhttp.internal.http.HttpURLConnectionImpl.connect()V + 89 (HttpURLConnectionImpl.java:89)
22 IOSLauncher                    0x10299cf98 [J]com.android.okhttp.internal.http.HttpURLConnectionImpl.getOutputStream()Ljava/io/OutputStream; + 199 (HttpURLConnectionImpl.java:199)
23 IOSLauncher                    0x10299fa64 [J]com.android.okhttp.internal.http.HttpsURLConnectionImpl.getOutputStream()Ljava/io/OutputStream; + 254 (HttpsURLConnectionImpl.java:254)
24 IOSLauncher                    0x102bbcef0 [J]com.badlogic.gdx.net.NetJavaImpl$2.run()V + 213 (NetJavaImpl$2.java:213)
25 IOSLauncher                    0x102ec1750 [J]java.util.concurrent.Executors$RunnableAdapter.call()Ljava/lang/Object; + 423 (Executors$RunnableAdapter.java:423)
26 IOSLauncher                    0x102ecf094 [J]java.util.concurrent.FutureTask.run()V + 237 (FutureTask.java:237)
27 IOSLauncher                    0x102eda8f4 [J]java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V + 1120 (ThreadPoolExecutor.java:1120)
28 IOSLauncher                    0x102edd0a0 [J]java.util.concurrent.ThreadPoolExecutor$Worker.run()V + 588 (ThreadPoolExecutor$Worker.java:588)
29 IOSLauncher                    0x102d8fa34 [J]java.lang.Thread.run()V + 839 (Thread.java:839)
30 IOSLauncher                    0x10372b614 _call0 + 234072
31 IOSLauncher                    0x103721778 callVoidMethod + 193468
32 IOSLauncher                    0x10372139c rvmCallVoidInstanceMethodA + 192480
33 IOSLauncher                    0x10372ab1c startThreadEntryPoint + 231264
34 IOSLauncher                    0x103744580 GC_inner_start_routine + 336324
35 IOSLauncher                    0x10374153c GC_call_with_stack_base + 323968
36 IOSLauncher                    0x103745ae0 GC_start_routine + 341796
37 libsystem_pthread.dylib        0x1ccb33cb0 _pthread_start + 320
38 libsystem_pthread.dylib        0x1ccb3c778 thread_start + 8

[WillCalderwood]

I fire off a few http requests in quick succession. I'm wondering if there's something that's not thread safe. It would surprise me if that was the case, but it's all I can think of right now.

I'm releasing a version without the http requests to see if that resolves the issue. This will hopefully help narrow it down.

[WillCalderwood]

I have seen no reports of the error since removing the 3 HTTP requests fired in quick succession. I'll change my back end so that all 3 can be combined into a single request which I'm guessing will resolve my problem. I'll try to create a simple test program to recreate the issue.

[dkimitsa]

fix proposed in #564, more details in post

[dkimitsa]

small comment: issue is happening when:

• producing multiple TLS connections to single server that is subject of SSL session caching(sharing).
• server supports TLS extensions (happens with google.com, will not happen with https://howsmyssl.com for ex)

[WillCalderwood]

Thanks for looking into the cause of this. At least there are workarounds.

[guillerodriguez]

@WillCalderwood This should now be fixed in RoboVM 2.3.13 via #564 (your original report mentions this happened in "2.3.13" but I assume that was a snapshot and not the final release). You might want to close the issue.

[WillCalderwood]

Thanks for that. I'll update to the latest version and confirm fixed.