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

Targets macOS
1

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?

2

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.

3

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

5

@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.

6

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.

7

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

8

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.

9

@Greg_O and @Rick_Araujo 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: