Hard crash during HTTPSecureSocket.Post request inside thread. (ARM-only)

Hardware: Macbook Pro M1 Max (64GB)
OS: MacOS 12.2.1
Xojo: 2021r3.1

Build Scenarios:
Build: ARM -> Target: ARM/Intel (crash)
Build: Intel -> Target: ARM (crash)
Build: Intel -> Target: Intel (ok)

Hi All,

Apologies in advance for the following semi-scattered question. Full disclosure, the application is not mine originally, and I’m unable to release any of the source as the application is proprietary with all kinds of NDA “goodness”. :weary:

That said, I’m having an issue with an a deeply nested HTTPSocket.Post that is ultimately running inside a thread. The app hard crashes (both build and debug) in the exact same manner every time (see crash log excerpt):

Thread 6 Crashed:
0   libsystem_pthread.dylib       	       0x1854bc064 ___chkstk_darwin + 60
1   SSLSocket.dylib               	       0x1135dceec 0x1134d0000 + 1101548
2   SSLSocket.dylib               	       0x1135dca60 0x1134d0000 + 1100384
3   SSLSocket.dylib               	       0x1135dcbc0 0x1134d0000 + 1100736
4   SSLSocket.dylib               	       0x1135daba8 0x1134d0000 + 1092520
5   CustomApp                      	       0x104d75ab4 SSLSocket.Close%%o<SSLSocket> + 60
6   CustomApp                      	       0x104e0e034 HTTPSecureSocket._ProcessData%%o<HTTPSecureSocket>s + 508
7   CustomApp                      	       0x104e0cc48 HTTPSecureSocket._HandleNewData%%o<HTTPSecureSocket> + 2564
8   CustomApp                      	       0x104e0624c HTTPSecureSocket.Event_DataAvailable%%o<HTTPSecureSocket> + 56
9   SSLSocket.dylib               	       0x1135dd574 0x1134d0000 + 1103220
10  SSLSocket.dylib               	       0x1135dd498 0x1134d0000 + 1103000
11  SSLSocket.dylib               	       0x1135dd044 0x1134d0000 + 1101892
12  SSLSocket.dylib               	       0x1135dca70 0x1134d0000 + 1100400
13  SSLSocket.dylib               	       0x1135db3dc 0x1134d0000 + 1094620
14  SSLSocket.dylib               	       0x1135dbd7c 0x1134d0000 + 1097084
15  CustomApp                      	       0x104d75bec SSLSocket.Poll%%o<SSLSocket> + 60
16  CustomApp                      	       0x104e08884 HTTPSecureSocket.WaitForPage%%o<HTTPSecureSocket> + 404
17  CustomApp                      	       0x104e07bac HTTPSecureSocket.Post%s%o<HTTPSecureSocket>si8 + 128
18  CustomApp                      	       0x106eac300 SOAPSocket.SendRequest%s%o<SOAPSocket>sss + 5856
19  CustomApp                      	       0x106ebc3e4 SOAPClient.sendSoapRequest%%o<SOAPClient>si8sb + 6276
20  CustomApp                      	       0x106ebaaf4 SOAPClient.sendSoapRequest%%o<SOAPClient>si8s + 148
21  CustomApp                      	       0x106c07df0 SoapDish.sendSoapRequest%%o<SoapDish>sb + 10792
22  CustomApp                      	       0x106c05174 SoapDish.sendRequest%%o<SoapDish>s + 132
23  CustomApp                      	       0x106c05084 SoapDish.sendRequest%%o<SoapDish> + 108
24  CustomApp                      	       0x10685b220 DoDBUpdate.execute%%o<DoDBUpdate> + 5368
25  CustomApp                      	       0x10bc6be90 CMDashboardWindow.CMDashboardWindow.loadMessages%%o<CMDashboardWindow.CMDashboardWindow> + 5588
26  CustomApp                      	       0x10bc13634 CMDashboardWindow.CMDashboardWindow.LoadMessagesThread_Run%%o<CMDashboardWindow.CMDashboardWindow>o<Thread> + 592
27  CustomApp                      	       0x10585351c Delegate.IM_Invoke%%o<Thread> + 60
28  XojoFramework                 	       0x10eee7500 0x10ecc8000 + 2225408
29  XojoFramework                 	       0x10edb0678 0x10ecc8000 + 951928
30  libsystem_pthread.dylib       	       0x1854c1240 _pthread_start + 148
31  libsystem_pthread.dylib       	       0x1854bc024 thread_start + 8

As it is a hard crash, no actionable error (unhandled exception or otherwise) is presented. Further, symbolication provides no useful information.

Interestingly, if I move the code outside the thread, the app temporarily hangs (as expected), but runs fine.

FYI, there is no UI being updated inside the thread, and no 3rd-party plugins being used in the process, but there is a timer that runs “in parallel” that checks for data written by the thread that then updates the UI. Also, I realize that HTTPSecureSocket is deprecated, but the workflow required by URLConnection isn’t really desirable at the moment.

Any recommendations as to where I might look or how I might further debug this issue?

It looks like you are closing the SSLSocket within a call to SSLSocket.Poll. Killing off the SSLSocket during the Poll event is likely causing your problem. It is best not to destroy objects within a call to one of its methods:

0x104d75ab4 SSLSocket.Close%%o<SSLSocket> + 60
...
0x104d75bec SSLSocket.Poll%%o<SSLSocket> + 60

I had a similar issue when I was destroying a window within a call to one of its event handlers. I now set a flag (property on the class) and then check if I need to closedown the window outside of its event handler, solving the problem.

If you set a property on the SSLSocket to signal need to close and do the close in your timer, you will hopefully solve the problem.

Could you clarify that statement? For the most part they can be the same if you use SendSync.

@Greg_O
Apologies, you’re correct. I’d simply need to ReplaceAll .Post( with .SendSync('POST'. I’ll give that a go if none of the other rabbit holes pan out.

One issue I do have though is that some of the other classes that are subclassed from the “custom” (but not really) SOAPSocket class make use of methods that don’t exist in URLConnection, but I can sort that independently. :thinking:

@Ian_Kennedy
Thanks for the feedback.The interesting thing is, there are no “EventHandlers” in use. HTTPSecureSocket.Post returns a string and that string is stored to an array of results. I’m not using Poll or manually calling Close.

Alright, so an interesting discovery. Without changing a single letter of code, if I set the Xojo “Optimization Level” to “Aggressive”, it creates an ARM build that runs without issue – but building with default/moderate results in the usual crash. I’ve tested each build permutation multiple times. The primary down side of “Aggressive” is it actually increases the build time nearly 6-fold.

I’m going to work with this for now, but if anyone has any recommendations (despite my inability to share the source) I’m all ears.

You should file a reproducible bug report about that with Xojo. Changing compiler mode should not change whether or not your app crashes.

Looks like some kind of race condition. Optimizing speed or moving a resource to registers probably has hidden a problem that still exists but in the machine used in the test things got synchronized in a way that the clash did not occur. I hope that the thread and timer parts exchange info (flags or locks) avoiding such conditions.
I also remember someone pointing out that his ARM code fired his events in a unexpected different order from the same compiled source for X86. That’s another thing to have in mind.

@Greg_O and @Rick_A it took some reworking, but converting the code to use URLConnection rather than HTTPSecureSocket seems to have eliminated the crash. It appears that HTTPSecureSocket doesn’t enjoy threads on M1 – at least in the manner we were using them.

Anyway, I’m going to skip logging a bug report on this one as I simply replaced the implementation rather than seek out the specific offending code. Thanks for the feedback and letting me talk it through. :woozy_face: