Hard to pin down crash

I’m struggling to pin down an intermittent hard crash of the app I’m developing and I wonder if anyone can help me?

I’m working on a code editor and the crash happens when I paste a large volume of text into the editor. It only happens occasionally and sometimes the pasted text causes the crashes but then pasting the same text again doesn’t cause the crash.

I have attached the macOS crash log below and I’m wondering if this is a bug in my NextToken method or if it’s a problem with the Xojo framework since it seems to say:

pointer being freed was not allocated

Any thoughts how to debug this further?

Process:               Better Code Editor Dev Harness.debug [21181]
Path:                  /Users/USER/*/Better Code Editor Dev Harness.debug.app/Contents/MacOS/Better Code Editor Dev Harness.debug
Identifier:            com.garrypettet.better-code-editor-dev-harness
Version:               ??? (1.0.0.0.0)
Code Type:             ARM-64 (Native)
Parent Process:        ??? [1]
Responsible:           Better Code Editor Dev Harness.debug [21181]
User ID:               501

Date/Time:             2021-08-15 07:54:20.063 +0100
OS Version:            macOS 11.5.1 (20G80)
Report Version:        12
Anonymous UUID:        2C3CE5B0-9614-8108-10F6-FD4A0A634A14

Sleep/Wake UUID:       9E05AB15-E0F8-4B5A-9BF1-66C3EFA0020B

Time Awake Since Boot: 43000 seconds
Time Since Wake:       730 seconds

System Integrity Protection: enabled

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

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
Performing @selector(menuItemAction:) from sender NSMenuItem 0x6000002f5490
abort() called
Better Code Editor Dev Harness.debug(21181,0x104a9bd40) malloc: *** error for object 0x12c70e697: pointer being freed was not allocated
 

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x0000000199714e68 __pthread_kill + 8
1   libsystem_pthread.dylib       	0x000000019974743c pthread_kill + 292
2   libsystem_c.dylib             	0x000000019968f454 abort + 124
3   libsystem_malloc.dylib        	0x0000000199577ecc malloc_vreport + 560
4   libsystem_malloc.dylib        	0x000000019957b514 malloc_report + 64
5   libsystem_malloc.dylib        	0x000000019956a5cc free + 516
6   com.xojo.XojoFramework        	0x0000000104cf1cbc RuntimeUnlockObject + 904
7   com.garrypettet.better-code-editor-dev-harness	0x000000010437f358 DartFormatter.NextToken%%o<DartFormatter> + 15840 (/DartFormatter:301)
8   com.garrypettet.better-code-editor-dev-harness	0x000000010437925c DartFormatter.TokeniseLine%%o<DartFormatter>o<BCELine> + 220 (/DartFormatter:67)
9   com.garrypettet.better-code-editor-dev-harness	0x000000010441ec00 BCELine.Tokenise%%o<BCELine> + 2040 (/BCELine:807)
10  com.garrypettet.better-code-editor-dev-harness	0x000000010440e468 BCELine.=Contents%%o<BCELine>bby + 604 (/BCELine:98)
11  com.garrypettet.better-code-editor-dev-harness	0x000000010440df64 BCELine.Constructor%%o<BCELine>o<BCELineManager>i8i8i8y + 844 (/BCELine:67)
12  com.garrypettet.better-code-editor-dev-harness	0x0000000104448e74 BCELineManager.InsertText%%o<BCELineManager>i8ybb + 24956 (/BCELineManager:649)
13  com.garrypettet.better-code-editor-dev-harness	0x00000001043e28e0 BCECanvas.Insert%%o<BCECanvas>yi8b + 1452 (/BCECanvas:1345)
14  com.garrypettet.better-code-editor-dev-harness	0x0000000104347e18 WinEditor.WinEditor._EditPaste_Action%b%o<WinEditor.WinEditor> + 2244 (/WinEditor:199)
15  com.xojo.XojoFramework        	0x0000000104c50024 InvokeMenuHandler(RunMenuItem*, unsigned char, Window*, unsigned char&) + 1008
16  com.xojo.XojoFramework        	0x0000000104c50300 RuntimeMenuItemClick(RunMenuItem*, unsigned char, Window*, unsigned char*) + 116
17  com.xojo.XojoFramework        	0x0000000104b58068 CocoaMenu::_MenuItemAction(NSMenuItem*) + 76
18  com.xojo.XojoFramework        	0x0000000104b586f0 0x104ae8000 + 460528
19  com.apple.AppKit              	0x000000019c24e460 -[NSApplication(NSResponder) sendAction:to:from:] + 456
20  com.apple.AppKit              	0x000000019c34d764 -[NSMenuItem _corePerformAction] + 444
21  com.apple.AppKit              	0x000000019c34d454 -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 100
22  com.apple.AppKit              	0x000000019c34c410 -[NSMenu performKeyEquivalent:] + 412
23  com.apple.AppKit              	0x000000019c7ad868 routeKeyEquivalent + 444
24  com.apple.AppKit              	0x000000019c1b64b8 -[NSApplication(NSEvent) sendEvent:] + 1176
25  com.xojo.XojoFramework        	0x0000000104b76b64 0x104ae8000 + 584548
26  com.garrypettet.better-code-editor-dev-harness	0x000000010427a990 Application._CallFunctionWithExceptionHandling%%o<Application>p + 164
27  com.xojo.XojoFramework        	0x0000000104cef384 CallFunctionWithExceptionHandling(void (*)()) + 180
28  com.xojo.XojoFramework        	0x0000000104b76b14 0x104ae8000 + 584468
29  com.apple.AppKit              	0x000000019c483bac -[NSApplication _handleEvent:] + 76
30  com.apple.AppKit              	0x000000019c0262b8 -[NSApplication run] + 636
31  com.xojo.XojoFramework        	0x0000000104cedc64 RuntimeRun + 48
32  com.garrypettet.better-code-editor-dev-harness	0x00000001042ee82c REALbasic._RuntimeRun + 28
33  com.garrypettet.better-code-editor-dev-harness	0x000000010449694c _Main + 712 (/#main:107)
34  com.garrypettet.better-code-editor-dev-harness	0x0000000104495ba4 main + 36
35  libdyld.dylib                 	0x0000000199765430 start + 4

Does DartFormatter.NextToken use any declares?

Seeing the code in that method may be helpful too, unfortunately that offset (15840) is large enough that it may not actually point to your code.

If we can’t resolve it here, file a bug report which includes the crash report and the built app which produces this error and we’ll see what we can do.

1 Like

Nope. I don’t think there’s any declares at all in the project. The only non-Xojo thing I’m using is the TextInputCanvas (built by MonkeyBread Software).

Whilst I’m unable to catch the error (the app just hard crashes) I think I can reproduce it. It’s crashing immediately after pasting in 4543 characters copied from a different app.

How is it copied?

I’m copying the text from Nova (Panic’s macOS code editor). I then paste it using Cmd-V. I have implemented a MenuHandler that gets the clipboard contents, converts to Text using .ToText and then inserts the text using a method I have written.

I have only just started experiencing this bug with large amounts of text. I haven’t had it happen with small amounts of text so I’m not sure if that’s at all related.

@Greg_O_Lone: I’ve created a private Feedback case: <https://xojo.com/issue/65562>.

I’ve attached the project, the text to paste in, a video of the crash and the TextInputCanvas I’m using.

1 Like

I’ve seen plenty of crashes like this, in my experience they can be very hard to pinpoint, as for me, the instigator is normally releasing an object in Apple’s toolbox, which is then also released somewhere else in the framework.

I know you said you don’t think that there are any declares in your project, but do a search for “release” and “AutoRelease” just in case.

Thanks Sam. No results for those terms.

The only non-native thing in the project is the TextInputCanvas that is hosted by @Christian_Schmitz. Not sure if the bug is within that code or the framework.

I’m just hoping @Greg_O_Lone can shed some light on it because as it stands, the project is probably dead since I have a code editor app that hard crashes when text is pasted. Given that I can’t catch the error (as no exception is raised) I can’t really move forwards.

Tcks… :grimacing:

So it crashes unlocking an object reference.
Which object reference?
Do you know what object is touched?
What methods are used on the same object otherwise, maybe a plugin function or a declare?

From time to time we find bugs in our plugin code or in the xojo framework, where the reference count management is not done correctly. a missing RuntimeLockObject or a RuntimeUnlockObject too much and the reference count is wrong. That causes a crash later in the code.

I’m not used to analysing the macOS crash logs (a snippet of one I pasted in the opening post) but from what I can see the crash happens in a method called NextToken. That method is called from TokeniseLine which gets called on every character change (and therefore many times if a large amount of text is pasted). NextToken branches out into dozens and dozens of helper methods but I have no way to step through the code to see where the issue is.

What’s weird is that the crash doesn’t happen every time the same text is pasted.

This:

Performing @selector(menuItemAction:) from sender NSMenuItem 0x6000002f5490
abort() called

suggests to me that the issue is triggered by my MenuHandler? If so, then surely this is a framework bug?

I’ve not seen that acronym before.

Its that funny noise you make when you go Tsck… Oh, I typoed it earlier, oops… sorry.

Well, to further complicate things, I cannot reproduce the crash on my Intel development machine. I’ll copy this all over to our M1 testing machine and see if it manifests over there.

1 Like

Confirmed. M1 Only.

Have you been able to reproduce it? I’ve added some more information to the private case. It’s nothing to do with the menu handler.

@GarryPettet
Could you confirm something for me? What I’m seeing here is that it only manifests when built as a universal binary, but not when it’s just an ARM build.

Um… if your conclusion is correct (about it happening on Editor.Insert) then the problem may be in the Plugin itself. We’ll need @Christian_Schmitz to look at this to move forward.

Editor.Insert is a method I’ve added. InsertText is the TextInputCanvas event.

I’m seeing the crash less often on x86 but equally as frequent with the ARM build.

Interestingly the Intel build (when it did crash) seemed to suggest an issue with variant to string. It also crashed once with a TypeMismatchException so I’m not sure if there is an issue with strings and Text in dictionary values but it’s not reliably being caught.

But that’s something that you can deal with using a Try-Catch and probably not the issue here.