"BUG IN LIBDISPATCH: Unexpected event" ?

[Q] Are there any known common reasons/patterns why libdispatch would face unexpected events?

Application Specific Information:
BUG IN LIBDISPATCH: Unexpected event

...

0 _dispatch_mach_reply_merge_evt + 29
1 _dispatch_kq_drain + 166
2 _dispatch_event_loop_drain + 312
3 _dispatch_lane_serial_drain + 803
4 _dispatch_lane_invoke + 366
5 _dispatch_workloop_worker_thread + 811
6 _pthread_wqthread + 314
7 start_wqthread + 15

There’s also a bit of a mystery with this backtrace as the libdispatch source code (from https://opensource.apple.com/releases) does not list _dispatch_mach_reply_merge_evt (or dux_merge_evt) as being called by _dispatch_kq_drain.

Are there any known common reasons/patterns why libdispatch would face unexpected events?

Presumably the snippet you posted is from a crash report. Please post the full report. See Posting a Crash Report for advice on how to do that.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

This crash report suggests that you’re running this app under Rosetta. Is that expected? Do you see this problem when you run native? That is, Intel on Intel or Apple silicon on Apple silicon?

Also, you’ve elided stuff from the crash report — most notably, the full content of the Binary Images section — that prevents me from using it. Please re-post without that elision.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I agree that the Rosetta entry at the end of the Binary Images is a bit mysterious. This is a Universal binary running native according to the "Code Type" field. As far as I know, it's Intel on Intel.

I can add the missing Binary Images section. Will re-post.

Thanks for the latest log. With that I was able to get a better symbolication of the issue and then figure out some details (not the whole story, mind you).

To start, here’s a minimal backtrace

0 libdispatch.dylib        … _dispatch_mach_reply_merge_evt + 29 …
1 libdispatch.dylib        … _dispatch_kq_drain + 166 …
2 libdispatch.dylib        … _dispatch_event_loop_drain + 312 …
3 libdispatch.dylib        … _dispatch_lane_serial_drain + 803 …
4 libdispatch.dylib        … _dispatch_lane_invoke + 366 …
5 libdispatch.dylib        … _dispatch_workloop_worker_thread + 811 …
6 libsystem_pthread.dylib  … _pthread_wqthread + 314 …
7 libsystem_pthread.dylib  … start_wqthread + 15

Frame 0 is this line, with the message Unexpected EV_VANISHED (do not destroy random mach ports). More on this below.

Note My links are to the Darwin open source aligned with macOS 11.5, which is the closest to the 11.6 in your crash report.

Earlier you wrote:

as the libdispatch source code … does not list _dispatch_mach_reply_merge_evt (or dux_merge_evt) as being called by _dispatch_kq_drain.

Oh, that would be too easy (-: Dispatch is heavily inlined and the symbolication in a crash report can’t see through that inlining. Here’s the sequence (I think :-):

  1. _dispatch_kq_drain calls _dispatch_kevent_drain in a couple of places, for example here.

  2. _dispatch_kevent_drain calls _dispatch_kevent_merge here.

  3. _dispatch_kevent_merge calls dux_merge_evt here.

  4. dux_merge_evt is a macro defined here.

  5. dux_merge_evt calls the dst_merge_evt function pointer, which is set up here to point to _dispatch_mach_reply_merge_evt.


Coming back to the big picture, the EV_VANISHED flag is defined in <sys/event.h> in the public macOS SDK, with the comment report that source has vanished. Tracing through that in the kernel (xnu) code it’s meaning is pretty clear: It’s delivered to the kqueue client (if it requests it) when the underlying object disappears while the client is monitoring it. The error message in the assert makes it clear that the underlying object in this case is a Mach port.

As to how this might come about, well, sheesh, there could be any number of reasons. Something is destroying a Mach port out from underneath Dispatch and there’s no easy way to work out what that might be.

Looking at the other threads in your crash report, the only one doing work is thread 11. Most of that backtrace is your code, so I don’t have any insight into it. It would be worthwhile to look at that code to see if it’s doing anything that might trigger this issue.

Having said that, thread 11 could just be an innocent bystander. The thread that destroyed the Mach port could already have disappeared itself. Or blocked in some innocuous location. Or be running in another process entire (any Mach grand?).

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks a lot. I will try to figure out if there are some suspicious Mach port actions in thread 11.

"BUG IN LIBDISPATCH: Unexpected event" ?
 
 
Q