It seems that kqueue code maintains subscriptions in subs_hash_table hash table.
I think that there can be a race process_kqueue_notifications() and _kh_cancel_sub() as there is no synchronization between those methods beyond hash_lock that's held only while the table is being accessed.
Imagine the following scenario:
- process_kqueue_notifications() is called to process a notification
- it looks up the hash table and finds a subscription
- concurrently with that g_kqueue_file_monitor_cancel() is called in another thread
- it calls _kh_cancel_sub() to remove the subscription
- g_kqueue_file_monitor_cancel() proceeds to free the subscription object
- after that process_kqueue_notifications() may access freed memory

I think that either the subscription objects should be reference counted.
Or there should be a more coarse lock that would protect the subscription object while it's being used.

I believe that the following crash was caused by the described race condition:

(gdb) bt

+ Trace 237165

(gdb) i loc
n = {fd = 35, flags = 2}
sub = 0x81be7b090
source = 0x81ce9da80
mask = G_FILE_MONITOR_EVENT_CHANGED
(gdb) p *sub
$8 = {filename = 0x5a5a5a5a5a5a5a5a <error: Cannot access memory at address 0x5a5a5a5a5a5a5a5a>, user_data = 0x5a5a5a5a5a5a5a5a, pair_moves = 1515870810, fd = 1515870810, deps = 0x819778b60, is_dir = 1515870810}

(gdb) p subs_hash_table
$9 = (GHashTable *) 0x81c16a4c0
(gdb) p *subs_hash_table
$10 = {size = 32, mod = 31, mask = 31, nnodes = 10, noccupied = 11, keys = 0x81be87700, hashes = 0x81be69800, values = 0x81be87900, hash_func = 0x80cc79c80 <g_direct_hash>, key_equal_func = 0x80cc7ba70 <g_direct_equal>, 
  ref_count = 1, version = 12, key_destroy_func = 0x0, value_destroy_func = 0x0}

(gdb) p *subs_hash_table->keys@32
$14 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x0 <repeats 17 times>}

Please note that 0x5a is a marker of freed memory (I enabled that feature in jemalloc) and that fd=35 is missing from the hash table.