Fatal Exception: std::__1::system_error mutex lock failed: Invalid argument

[zhfeng20108]

[gkassabli]

This is likely happening during the system teardown when application is closing, so I don't think crash is relevant.
If you think this is happening in other conditions, please post more detailed explanation how to reproduce the issue.

[yanni-fe]

@zhfeng20108 Are you still having this problem? Can you reproduce this issue?

[zhfeng20108]

This issue happened too much. Is there a way to avoid it?

[zhfeng20108]

@gkassabli

[ocrickard]

Wait, this is an error in mutex locking? That is almost certainly a heap corruption. It's crashing at this line, but the reason it is crashing is that the mutex has been stomped by some other code.

Historically, TextKit has had lots of hidden thread-safety issues despite being stated as thread safe. CK locks around all access to TextKit, but there are still issues that have cropped up in the recent past. We built the same text locking system in both CK and ASDK, and they both work this way.

Are there any other users of CK that run into the same issue? If so, then it's possible that there's a stomper inside the TextKit wrappers in CK itself (though, I doubt that).

If this is only happening in your app, then it's possible that your app is stomping the memory through an unprotected access.

(disclaimer, I don't work on CK anymore, just an avid observer. I won't be able to help with any actual fixes)

[ocrickard]

Oh god, wait, someone should check that the static mutex in the TextKit impl isn't susceptible to the static destructor fiasco. cc @adamjernst who will be able to check. That would probably manifest in this way if one thread is attempting to tear down while another thread tries to lock, right?

[ocrickard]

Specifically this line: https://github.com/facebook/componentkit/blob/master/ComponentTextKit/TextKit/CKTextKitContext.mm#L33

I'd appreciate @adamjernst or @eczarny checking on me that that line is correct, and won't crash on exit().

[ocrickard]

OK, looks like std::mutex is not trivially destructible in Clang, so we should probably just leak that mutex. Anyway, I believe this crash is happening on exit() as @gkassabli said above, so it probably has no impact on user experience.