Preemptive Thread Debugging

[Greg_O]

@Jon_Ogden

Since we are dealing with sockets, I supposed there could be a clash where the main thread is processing something with the socket and the thread is trying to read data from the socket.

I wouldn’t do that. Socket events always fire on the main thread and it’s entirely possible that more data could come in while the thread is processing data. Do yourself a favor and copy the incoming data into a memoryblock, send the memoryblock to the thread subclass and then start the thread.

[Kem_Tekinay]

Pepper your code with System.DebugLog statements as a way of tracing what it’s doing. That might help narrow it down.

[Jon_Ogden]

@Greg_O

@Jon_Ogden

Since we are dealing with sockets, I supposed there could be a clash where the main thread is processing something with the socket and the thread is trying to read data from the socket.

I wouldn’t do that. Socket events always fire on the main thread and it’s entirely possible that more data could come in while the thread is processing data. Do yourself a favor and copy the incoming data into a memoryblock, send the memoryblock to the thread subclass and then start the thread.

Actually I’m saving it to a string before calling the thread. I am not reading the socket from the thread. I did not type that correctly!

[Mike_D]

@Jon_Ogden

Not even getting those!

If you are on macOS, you should be getting nice symbolicated crash logs any time the app dies - open up Console.app, show the sidebar and look for Crash Logs. If you are on Windows, it’s not so easy.

[Jon_Ogden]

MacOS used to show the crash in a window. Not any more. I’ll have to brace console I guess.

[Mike_D]

The crash logs should be kept regardless, but if you want the dialog, you can reenable it:

defaults write com.apple.CrashReporter DialogType {none|basic|developer|server}

I believe “basic” is what you want:

defaults write com.apple.CrashReporter DialogType basic

[Tim_Hare]

The thread should receive a copy of the string and not refer to the string itself. I think that’s why Greg mentioned a memoryblock. Pass the memoryblock to the thread and then create a new one for future incoming data.

[Beatrix_Willius]

@Kem_Tekinay

Pepper your code with System.DebugLog statements as a way of tracing what it’s doing

The reduced project I sent to Xojo still has 300 classes. And there are multiple crashes. There still is a good chance that I’m doing something wrong. But I haven’t a clue what that is.

I’ve added more crash logs to my original bug report: https://tracker.xojo.com/xojoinc/xojo/-/issues/77356

[ChristopheDV]

@Beatrix_Willius

Ouch. I’m not a beginner. There are no common resources. Preemptive threads are flaky as heck for me and I don’t see any method of finding out what is crashing.

Same here. I am 100% sure what is happening in the thread cannot be accessed by anything else (main thread or another thread).
The crashes are also random here but when it happens the whole app just hardcrashes without log.
That way it is about impossible to debug.

[Kem_Tekinay]

Are either of you starting or changing Timers from within the thread?

[Beatrix_Willius]

The dock animation is running with a timer. Writing data to a database does not use a timer but writing to PDF does. I could check if writing to PDF crashes sooner.

[Greg_O]

I discovered yesterday that preemptive threads that create URLConnection objects crash with a SegFault after a time. That was fun.

[kevin_g]

Did you log a bug?

[Jon_Ogden]

@Greg_O

I discovered yesterday that preemptive threads that create URLConnection objects crash with a SegFault after a time. That was fun.

I wonder if something similar is happening to me. I’m not creating URLConnection objects but I am using one…

And it looks like my code crashed during operations with the URLConnection.

[Jon_Ogden]

@Tim_Hare

The thread should receive a copy of the string and not refer to the string itself. I think that’s why Greg mentioned a memoryblock. Pass the memoryblock to the thread and then create a new one for future incoming data.

What is special about a memory block as opposed to a string? I get not passing the string but why not save it to a different string? Why a memory block?

[Kem_Tekinay]

Strings are immutable and I’ve not encountered any issues accessing a string (or any intrinsic property, for that matter) from multiple threads.

[Mike_D]

@Beatrix_Willius and @Christian_Schmitz looking at that crash log, I notice it’s crashing in

• code within a Modal dialog MyBackgroundTaskProcRunOnMainThread (XojoFramework)
• within a MBS function MyBackgroundTaskProcRunOnMainThread (MBS_Util_Calls_Plugin_21114.dylib)

I wouldn’t be surprised if one, or both of these in combination are related.
What version of MBS Plugins are you using?

Crashed Thread

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   XojoFramework                 	       0x107ff2cb0 0x107e88000 + 1486000
1   CoreFoundation                	       0x19d0e8184 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32
2   CoreFoundation                	       0x19d0e7e28 __CFRunLoopDoTimer + 1012
3   CoreFoundation                	       0x19d0e7938 __CFRunLoopDoTimers + 356
4   CoreFoundation                	       0x19d0cd0f0 __CFRunLoopRun + 1856
5   CoreFoundation                	       0x19d0cc334 CFRunLoopRunSpecific + 572
6   HIToolbox                     	       0x1a850a0cc RunCurrentEventLoopInMode + 292
7   HIToolbox                     	       0x1a850febc ReceiveNextEventCommon + 636
8   HIToolbox                     	       0x1a8510020 _BlockUntilNextEventMatchingListInModeWithFilter + 76
9   AppKit                        	       0x1a0c0fa70 _DPSNextEvent + 660
10  AppKit                        	       0x1a15357b8 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
11  XojoFramework                 	       0x107f6e668 0x107e88000 + 943720
12  XojoFramework                 	       0x107f6d84c CocoaProcessOneEvent(bool) + 196
13  XojoFramework                 	       0x1080f551c ModalEvents(unsigned char) + 104
14  XojoFramework                 	       0x10810b8a8 RuntimeShowModalWithinWindow + 424
15  Mail Archiver X.debug         	       0x102becaf0 Window.ShowModalWithin%%o<Window>o<Window> + 48
16  Mail Archiver X.debug         	       0x103b48d0c ProgressWindow.ProgressWindow.ShowWindow%%o<ProgressWindow.ProgressWindow> + 1240 (/ProgressWindow:928)
17  MBS_Util_Calls_Plugin_21114.dylib	       0x10edf0520 MyRunOnMainThreadBlock(void*) + 180
18  MBS_Util_Calls_Plugin_21114.dylib	       0x10edfba80 MyBackgroundTaskProcRunOnMainThread(void*) + 100
19  XojoFramework                 	       0x107ff2cbc 0x107e88000 + 1486012
20  CoreFoundation                	       0x19d0e8184 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32
21  CoreFoundation                	       0x19d0e7e28 __CFRunLoopDoTimer + 1012
22  CoreFoundation                	       0x19d0e7938 __CFRunLoopDoTimers + 356
23  CoreFoundation                	       0x19d0cd0f0 __CFRunLoopRun + 1856
24  CoreFoundation                	       0x19d0cc334 CFRunLoopRunSpecific + 572
25  HIToolbox                     	       0x1a850a0cc RunCurrentEventLoopInMode + 292
26  HIToolbox                     	       0x1a850febc ReceiveNextEventCommon + 636
27  HIToolbox                     	       0x1a8510020 _BlockUntilNextEventMatchingListInModeWithFilter + 76
28  AppKit                        	       0x1a0c0fa70 _DPSNextEvent + 660
29  AppKit                        	       0x1a15357b8 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
30  XojoFramework                 	       0x107f6e668 0x107e88000 + 943720
31  XojoFramework                 	       0x107f6e6f0 0x107e88000 + 943856
32  Mail Archiver X.debug         	       0x102c2432c Application._CallFunctionWithExceptionHandling%%o<Application>p + 164
33  XojoFramework                 	       0x1080f5428 CallFunctionWithExceptionHandling(void (*)()) + 180
34  XojoFramework                 	       0x107f6e68c 0x107e88000 + 943756
35  AppKit                        	       0x1a0c02b7c -[NSApplication run] + 480
36  XojoFramework                 	       0x1080f3ba8 RuntimeRun + 60
37  Mail Archiver X.debug         	       0x102d71718 REALbasic._RuntimeRun + 28
38  Mail Archiver X.debug         	       0x1058601c4 _Main + 632 (/#main:5237)
39  Mail Archiver X.debug         	       0x1058269f4 main + 36
40  dyld                          	       0x19cc64274 start + 2840

[Jon_Ogden]

@Kem_Tekinay

Strings are immutable and I’ve not encountered any issues accessing a string (or any intrinsic property, for that matter) from multiple threads.

So there should be no issue reading from a string at the same time another operation may want to write to it?

[TimStreater]

You can’t write to a string; it’s immutable.

[Mike_D]

“In theory” it should be OK. Xojo strings being immutable means that an operation such as

var s as string = "Dog"
s = s + "Cat"

appears as if the string variable s is being modified, but in fact what’s happening is a new s is created and the old s is destroyed. This happens invisibly.