Occasional application crash

Has anyone seen a crash when setting DesktopWindow.Top to a new value. It is somewhat random but this is the start of the crash log:

Translated Report (Full Report Below)

Process:               C-Stat.debug [25740]
Path:                  /Users/USER/Documents/*/C-Stat.debug.app/Contents/MacOS/C-Stat.debug
Identifier:            C-Stat.debug
Version:               ???
Code Type:             ARM-64 (Native)
Parent Process:        launchd [1]
User ID:               504

Date/Time:             2023-05-14 20:06:56.5578 +0100
OS Version:            macOS 13.4 (22F63)
Report Version:        12
Anonymous UUID:        F92937B4-B744-046A-E67E-AC0DEC19787D

Sleep/Wake UUID:       C6AB32ED-0EDE-45FA-932C-22F5C87E6D79

Time Awake Since Boot: 140000 seconds
Time Since Wake:       5517 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000001, 0x0000000188007cd8

Termination Reason:    Namespace SIGNAL, Code 5 Trace/BPT trap: 5
Terminating Process:   exc handler [25740]

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   AppKit                        	       0x188007cd8 NSCGSPanicv + 228
1   AppKit                        	       0x188007bf4 NSCGSPanic + 32
2   AppKit                        	       0x188057050 -[NSCGSWindow(NCGSWindowMovement) moveTo:delta:isChildOfGroupMovement:] + 328
3   AppKit                        	       0x188057194 -[NSCGSWindow(NCGSWindowMovement) moveGroupTo:delta:isChildOfGroupMovement:] + 116
4   AppKit                        	       0x188057214 -[NSCGSWindow(NCGSWindowMovement) moveGroupTo:delta:isChildOfGroupMovement:] + 244
5   AppKit                        	       0x1876e3948 -[NSWindow _oldPlaceWindow:fromServer:] + 372
6   AppKit                        	       0x1876e2ac0 -[NSWindow _setFrameCommon:display:fromServer:] + 1832
7   XojoFramework                 	       0x10325b63c WindowImpCocoa::SetWindowPosition(xojo::Rect<xojo::Points>*, xojo::Value<xojo::Points>, xojo::Value<xojo::Points>) + 200
8   XojoFramework                 	       0x103416be4 Window::MoveWindow(xojo::Value<xojo::Points>, xojo::Value<xojo::Points>, unsigned char) + 32
9   XojoFramework                 	       0x1033c9284 windowPosSetter + 524
10  C-Stat.debug                  	       0x101229bbc DesktopWindow.Top.Set%%o<DesktopWindow>i4i8 + 64
11  C-Stat.debug                  	       0x10147aa34 CSW.CSW.LoadComplete%%o<CSW.CSW> + 4116 (/CSW:3646)
12  C-Stat.debug                  	       0x1011a1994 _CallLaterTimer.Event_Action%%o<_CallLaterTimer> + 212
13  XojoFramework                 	       0x1033bf05c 0x103148000 + 2584668
14  CoreFoundation                	       0x1844983c8 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32
15  CoreFoundation                	       0x184498070 __CFRunLoopDoTimer + 940
16  CoreFoundation                	       0x184497bc8 __CFRunLoopDoTimers + 356
17  CoreFoundation                	       0x18447d348 __CFRunLoopRun + 1852
18  CoreFoundation                	       0x18447c4b8 CFRunLoopRunSpecific + 612
19  HIToolbox                     	       0x18dcc6c40 RunCurrentEventLoopInMode + 292
20  HIToolbox                     	       0x18dcc6a7c ReceiveNextEventCommon + 648
21  HIToolbox                     	       0x18dcc67d4 _BlockUntilNextEventMatchingListInModeWithFilter + 76
22  AppKit                        	       0x18769dd44 _DPSNextEvent + 636
23  AppKit                        	       0x18769cee0 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716
24  XojoFramework                 	       0x10322c878 0x103148000 + 936056
25  XojoFramework                 	       0x10322c900 0x103148000 + 936192
26  C-Stat.debug                  	       0x1011df0f4 DesktopApplication._CallFunctionWithExceptionHandling%%o<DesktopApplication>p + 164
27  XojoFramework                 	       0x1033b6e9c CallFunctionWithExceptionHandling(void (*)()) + 180
28  XojoFramework                 	       0x10322c89c 0x103148000 + 936092
29  AppKit                        	       0x187691344 -[NSApplication run] + 464
30  XojoFramework                 	       0x1033b56f8 RuntimeRun + 48
31  C-Stat.debug                  	       0x101272e74 REALbasic._RuntimeRun + 28
32  C-Stat.debug                  	       0x1020aca70 _Main + 712 (/#main:969)
33  C-Stat.debug                  	       0x1020a2ed8 main + 36
34  dyld                          	       0x184047f28 start + 2236

Basically, the setup is as follows:

  • I have a thread that is loading a file.
  • This is monitored by a timer, which deals with a modal window with a progress bar.
  • The modal window prevents the window that is being loaded into from being closed etc.
  • When the thread is complete the timer detects this and calls LoadComplete via Timer.CallLater
  • The LoadComplete method finalises the user interface for the window, including restoring the window size and location.

It is during this that I get the crash. I’ve yet to post a bug report as I can’t easily reproduce this issue.

If you could create a sample simulating this part of your process, substituting your real charge by a loop with few sleeps instead of loading a file, it would help to understand the thing, and even help in a redesign of the process to obtain the desired result… Probably without your timers… not sure right now. But I have an intuition that it can be better done using another design.

The design is fairly standard. It’s even suggested by Xojo. I know there is now a thread II update method, which could be better.

I’m not overly interested in changing the design at this stage, unless there is something fundamentally wrong with it.

Pretty sure it has only started happening in the last couple of versions of Xojo. I may put a private report up with the project. Stripped down.

It could also be related to macOS 13.4 rc2. Which is on the machine.

Some things I can think of.

  1. Log the window position it is moving too and ensure that the width and height are > 0.
  2. This crash is occurring in the Xojo framework, they need to find and fix it. However experience tells me that you have a very slim chance of this getting fixed, zero chance if you can’t provide them with a project that can reproduce the problem.
  3. Does the desktopWindow support the frame rect (IIRC Xojo called this bounds in previous versions). Perhaps you can use this as a workaround?
  4. There are a bunch of declares that you can also use to set the window position, I’d suggest looking into those to figure out alternatives. Just be warned, Apple uses bottom up co-ordinates for the macOS, while Xojo uses Top Down (I personally think top-down is more logical).
1 Like

Just FYI, I do t think that it is. To me, it looks like the crash is on line 3

NSCGSWindow(NCGSWindowMovement) moveTo:delta:isChildOfGroupMovement:] + 328

Which appears to be a private framework that was added in Big Sur, possibly only for ARM.

I hope that’s not the case as they’re planning to ship tomorrow.

1 Like

I think you mean don’t? I had to read it a couple of times before I realized the “n” was issing…

The way I see it, unless @Ian_Kennedy is passing in weird values (like values that exceed a 64-bit CGFloat, or some other limitation we don’t know about), the problem is not his responsibility.

We also can’t see the values that passed between the 3 (what I assume are C++) Xojo functions before they hit the OS, so this gives plenty of potential for a function to mess up the values.

The function [NSWindow _oldPlaceWindow:fromServer:] does cause a little concern. Last time I saw an API identify that’s its old, it had already stopped working and I had to use an alternative.

Situations like this are why I lobbied for a dedicated macOS programmer, someone who can keep the framework up to date. Apple move at a frustratingly rabid pace, and its tiring just keeping Sleep Aid up to date. I had to make changes for 12.6.x, 13.3 and even 13.4… The longer Xojo goes without having a dedicated macOS person, the more they’re going to struggle.

@Ian_Kennedy In case it helps in any possible way. It is window.bounds that I use to restore a window’s position on re-open.

I forgot too about “window.bounds”… lately and had troubles (the window’s title above the MenuBar, etc.) until I use the same values, but set in a Bounds…

And then: it magically worked fine, placing the window where it belongs (for me) !

Yeah, I’m having that problem a lot lately. Don’t know if that’s me or that something has changed about the iOS keyboard recently.

mistakes a lot I make with mobile.

Mistakes is my alias :rage: (especially lately)


1 Like

Thanks for the many replies. I was actually in bed responding to some of these items, teaches me to post an issue last thing when USA and that part of the world is fully awake. :slight_smile:

I will look at the values but I don’t think they are going to be the issue, it is always the same window and in a perfectly ordinary, single monitor, place. Certainly worth checking.

I will take a look at window.bounds. One operation is better than 4 in any case. If the API under the hood is different it could help too.

As for refactoring, I’m sure there are better ways of doing things than 3 years ago when this process was put into place, however, I’m close to a release and don’t want to majorly refactor an item that has been working and stable for the last 3 years.

1 Like

So swapping to bounds rather than top etc does, at least so far, seem to have removed the problem. I’ve loaded 50 test files about 30 times now and not one crash. I’ll continue to test.

I will also try and track down a repeatable condition that can cause the original problem.

1 Like

If the problem is isolated to the final part of your process, “moving a window” setting x,y, h,w as

window.Top = n1
window.Left = n2
window.Width = n3
window.Height = n4


window.Visible = False

window.Top = n1
window.Left = n2
window.Width = n3
window.Height = n4

window.Visible = True

In hope that Xojo postpone visual changes and does it all at once when the visibility flag changes skipping a bug triggered by partial settings.

1 Like

DesktopWindow contains a property called Bounds. Prior to saving I now have a Window property called Bounds, which I assign Window.Bounds. This makes a Thread safe version that I am using when saving.

The bounds are then written to my file. On reloading I recreate a version of WindowBounds rect and then assign them to the window in the final method. Instead of:

x = n1
y = n2
w = n3
h = n4

I can now do:

MyWindow.Bounds = LoadedBounds

The window’s location and dimensions are then set in that one operation.

1 Like

Bounds is a rect, I never inspected it to see if is a struct or class, if struct it can can be saved as is, if object it must be serialized or you will get garbage. And there’s no thread safe visual operation, it must be set in the main (UI) thread, never from a user thread.
As you said it worked before, I assume you are doing the bounds part ok, but I’m afraid about where it is being set (UI or User thread).
Also not sure how Xojo is handling it under the hood.
If the bug is being triggered at

MyWindow.Bounds = LoadedBounds

From the UI thread, this may be worthy a try trying to workaround triggering the bug

MyWindow.Visible = False
MyWindow.Bounds = LoadedBounds
MyWindow.Visible = True

But if you are doing UI changes FROM an user thread, you should redesign your process.

Edit: I inspected Rect right now, it is a Class, so you must be serializing it.

As I pointed out I duplicate the Window.Bounds into a property so the thread is able to access the property and save it (obviously in a file friendly way) the thread never accesses Window.Bounds.

Equally, when I load the file it creates a new Rect in the threaded load process. In the Main thread when the process is complete I assign the thread created Rect to the Window.Bounds property. So far there hasn’t been any issue assigning to Bounds, rather than top, left, width and height.

So far I have not needed to hide the window while I assign Bounds.

To be clear:

// This triggers the error
Window.top = TopValue

// This, so far, does not
Window.Bounds = LoadedBounds
1 Like

So this is new? And you already fixed the issue using it?

Yes, it has been happening in the last couple of Xojo releases, but I’ve never been able to track it down.

So far Bounds has fixed the issue, but it is an occasional issue so hard to be sure.

1 Like