Previously this had to be done via global constructor functions but it would seem the execution of these may happen before initialization of global data.
Building with clang 3.2 (binary distribution) results in “illegal instruction” when adding 3 seconds to the steady clock, so I just replaced the code.
The reason the code was using std::chrono was to be able to provide better debug output, as dispatch_time_t is an abstracted time representation (according to the documentation).
A DFA node may be disposed as part of DFA construction (because the node is redundant) and here it would have “next” pointers setup, which it should not follow in its destructor, since those nodes could still be used.
Fixes#1086
For example when creating a new bundle (‘foo.tmBundle’) and then saving a new snippet in this bundle (‘bar.tmSnippet’) we may ask to rescan the ‘Snippets’ folder (in the bundle) before the bundle itself does a content (re)scan, which effectively makes the ‘Snippets’ rescan a no-op.
Should fix#1034
Previously it would only observe NSViewBoundsDidChange from the clip view containing the text view, and while it worked most of the time, it failed to see notifications when a text view was smaller than the clip view’s view port and grew, yet still staying smaller than the view port.
If libcurl is built with the default DNS resolver then it will handle a timeout by using SIGALRM, though since we are using threads, and signals are not compatible with threads, this may have led to a crash in Curl_resolv_timeout (for users where a DNS lookup could take longer than the timeout, presumably 300 seconds).
I’m seeing a crash in ‘-[OakDocumentView dealloc]’ stating that “selectionString” is not being observed. This would indicate that a OakDocumentView instance is created that doesn’t go through the designated initializer, how that can happen is beyond me, but with the reshuffled code, if it happens, it should no longer cause a crash in dealloc.
This is to avoid cyclic dependencies since it was previously in a somewhat high-level framework, so everything that framework depended on, could not augment crash reports.
The mutex was locked to ensure that the client object did not go away, but the client’s code may terminate the program which destroys the server_t instance and thereby the mutex itself, which would previously cause an assertion to trigger, since the mutex was locked during destruction.
In practice there is no issue with the mutex not being locked while accessing the client object, as “unregister_client” and “master_run” are both called from the main thread, except for tests, but here we do not unregister client objects before their requests have been handled.
It appears a window can hang around after its last tab has been closed. Such window receive notifications of items being deleted via the file browser, and will call the “close tabs” method in response to these, which does an out-of-range array access if no tabs exist.
The reason for why windows can hang around after last tab is closed has not yet been determined. It might be a retain cycle (bug) or a delayed release due to autorelease pools.
Fixes#1064
The first time we ask for the shared spell checker it does some setup involving AppKit (creating the shared spelling panel?). While we already ensure that the spell checker is only called from the main queue, it seems this setup code must run on thread 0, which, when we are not in a Cocoa application, is not necessarily the thread used for the main queue.
I have been told that the spell checker should be thread safe (except for the spelling panel) but after moving to concurrent execution of the integration tests, several segmentation faults have pointed toward the spell checker not being thread safe.
