On 15 Jul 2015, at 17:48, Rob McBroom wrote:

I tried to open a folder in TextMate today (one I open often) and it crashed. (It was already running, as always.) Ever since, I’ve been unable to get it to launch.

It detects the crash and asks about restoring open documents. It crashes no matter what I choose there.

You can hold down shift (⇧) to disable session restore during launch.

The dialog about restoring documents is misleading, as it’s an OS feature and does not have any effect on TextMate (and I have been unable to suppress it, though long-term it might be able to use the OS session restore system).

FYI the session to restore is in ~/Library/Application Support/TextMate/Session

Furthermore, it remembers “per folder” info in ~/Library/Application Support/TextMate/RecentProjects.db

On 15 Jul 2015, at 12:15, Rob McBroom wrote:

On 15 Jul 2015, at 12:00, Allan Odgaard wrote:

...

You can hold down shift (⇧) to disable session restore during launch.

Back in business. Thanks for the quick replies.

I’m running into this again, but disabling session restore isn’t cutting it this time. I can hold ⇧ and get the “By holding down shift” dialogue asking to disable it, but there’s still a crash.

Occasionally, it realizes it’s crashing and offers to disable session restore on its own, but choosing “Disable” doesn’t prevent the crash.

The crash reports are a little different with and without session restore, so the attempt to disable it is doing *something* at least.

``` Crashed Thread: 10

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

Application Specific Information: Assertion failed: (ec == 0), function unlock, file /BuildRoot/Library/Caches/com.apple.xbs/Sources/libcxx/libcxx-120.1/src/mutex.cpp, line 45.

Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_platform.dylib 0x00007fff88e4c551 _platform_memmove$VARIANT$Ivybridge + 49 1 com.macromates.TextMate.OakTextView 0x0000000102e2cc43 oak::callbacks_t<ng::callback_t, false>::remove(ng::callback_t*) + 97 2 com.macromates.TextMate.OakTextView 0x0000000102e05147 -[OakTextView setDocument:] + 437 3 com.macromates.TextMate.OakTextView 0x0000000102df73c4 -[OakDocumentView setDocument:] + 649 4 com.macromates.TextMate.OakTextView 0x0000000102df702a -[OakDocumentView dealloc] + 457 5 libobjc.A.dylib 0x00007fff8d3ab224 objc_object::sidetable_release(bool) + 242 6 libobjc.A.dylib 0x00007fff8d3a6094 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 476 7 com.apple.CoreFoundation 0x00007fff91a50d02 _CFAutoreleasePoolPop + 50 8 com.apple.AppKit 0x00007fff920b86f2 -[NSApplication finishLaunching] + 2098 9 com.apple.AppKit 0x00007fff920b7b65 -[NSApplication run] + 231 10 com.apple.AppKit 0x00007fff92080fbe NSApplicationMain + 1176 11 com.macromates.TextMate.preview 0x0000000102a471ef main + 840 12 com.macromates.TextMate.preview 0x0000000102a31d44 start + 52

…

Thread 10 Crashed: 0 libsystem_kernel.dylib 0x00007fff8c0b90ae __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff981e1500 pthread_kill + 90 2 libsystem_c.dylib 0x00007fff92f6337b abort + 129 3 libsystem_c.dylib 0x00007fff92f2a9c4 __assert_rtn + 321 4 libc++.1.dylib 0x00007fff880b5fc8 std::__1::mutex::unlock() + 46 5 libdispatch.dylib 0x00007fff909b28f5 _dispatch_call_block_and_release + 12 6 libdispatch.dylib 0x00007fff909a73c3 _dispatch_client_callout + 8 7 libdispatch.dylib 0x00007fff909abff3 _dispatch_queue_drain + 754 8 libdispatch.dylib 0x00007fff909b26bf _dispatch_queue_invoke + 549 9 libdispatch.dylib 0x00007fff909a73c3 _dispatch_client_callout + 8 10 libdispatch.dylib 0x00007fff909ab253 _dispatch_root_queue_drain + 1890 11 libdispatch.dylib 0x00007fff909aaab8 _dispatch_worker_thread3 + 91 12 libsystem_pthread.dylib 0x00007fff981de4f2 _pthread_wqthread + 1129 13 libsystem_pthread.dylib 0x00007fff981dc375 start_wqthread + 13 ```

Anything else I can try? Thanks.

On 10 Nov 2015, at 16:10, Ronald Wampler wrote:

Have you tried deleting the files in ~/Library/Application Support/TextMate/Session and deleting ~/Library/Application Support/TextMate/RecentProjects.db?

That worked. Thanks! I’m sure you didn’t see it, but I had tried that last time this problem came up (the start of this thread) with no luck, so I didn’t bother this time.

You may want to make a copy of the files so if it works you can email them to support for further trouble shooting.

I’ve still got the files if anyone cares to see them.

On 10 Nov 2015, at 22:13, Allan Odgaard wrote:

I’m almost certain it’s ~/Library/Application Support/TextMate/RecentProjects.db

Can you try move back that file and see if it then crashes?

I’m afraid that isn’t it.

First, I started getting crashes again tonight and that file hadn’t yet been recreated. Removing `Session/Info.plist` didn’t help and neither did launching without session restore, so I gave up for a while.

I accidentally got it working by doing [some command-line Git stuff][1] that called my $EDITOR (which is `mate_wait`), and suddenly it was able to run.

Second, I put the file from earlier today back and TextMate launches. I also put the files back into `Session` and still had no problems.

For what it’s worth, I got the first crash today when I had a project open already, and then tried to open another (unrelated and outside the project folder) file using the `mate` command.

the part of the crash log you quoted did not specifically point to CoreData, though it also did not point to any TextMate code.

True, but no matter which thread crashes, the main thread always seems to be doing the same thing when things go south.

Let me know if there’s anything else you want me to try. I don’t have the TextMate source set up and ready to build on my system, but I could set it up if necessary.

Thanks.

[1]: https://github.com/quicksilver/Quicksilver/commit/3c8815ab19630e88adba6cd027...

On 26 May 2016, at 17:27, Rob McBroom wrote:

And once again…

Just to acknowledge your report. Unfortunately from the crash report I can’t really tell what goes wrong, and it seems this issue is not widespread (i.e. experienced by less than a dozen users in total, and only two users for beta 9.2).

But I plan to do some refactoring that should simplify the code involved and hopefully thereby make the problem go away. Though this refactoring may take a while to complete as it is non-trivial.

On 31 May 2016, at 4:12, Allan Odgaard wrote:

Just to acknowledge your report. Unfortunately from the crash report I can’t really tell what goes wrong, and it seems this issue is not widespread (i.e. experienced by less than a dozen users in total, and only two users for beta 9.2).

But I plan to do some refactoring that should simplify the code involved and hopefully thereby make the problem go away. Though this refactoring may take a while to complete as it is non-trivial.

Thanks for the update.