Re: Deadlock when receiving kill-signal from child process

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Aug 9,  4:53pm, Mathias Fredriksson wrote:
} Subject: Re: Deadlock when receiving kill-signal from child process
}
} I'm wondering if I'm not getting the complete picture
} though since there are some "in ?? ()" also in there (I did build with
} debugging enabled though).

Did you "make install" before running this?  If so, *don't* -- run the
binary straight out of the build tree.  If you "make install" the symbol
table gets stripped even if you've compiled with debugging, which gives
you the incomplete stack traces you've been seeing.

In this case I think that's actually causing a misleading backtrace,
because:

} #17 <signal handler called>
} #18 0x00007fff896db4fe in tiny_free_list_remove_ptr ()
} #19 0x00007fff896d9b2e in szone_free_definite_size ()
} #20 0x0000000105d82ef6 in getredirs ()

There is already a queue_signals() around getredirs() so it should not
be calling a signal handler here, or at least the handler should not
be doing anything interesting.

Also this part doesn't make sense:

} #0  0x00007fff8abf95da in syscall_thread_switch ()
} #1  0x00007fff853a982d in _OSSpinLockLockSlow ()
} #2  0x00007fff896e1635 in szone_force_lock ()
} #3  0x00007fff896e15e6 in _malloc_fork_prepare ()
} #4  0x00007fff82cb8097 in fork ()
} #5  0x0000000105d3f960 in get_match_ret ()
} #6  0x0000000105d45463 in savehistfile ()

There's no call to get_match_ret() from savehistfile(), and it's pretty
unlikely that savehistfile is called at all, so this stack looks trashed
to me.  (My other guess would be you're using the new binary with an old
core file, but theoretically you're not reading a core file at all).

Also here:

} #36 0x0000000105d3d69f in gmatchcmp ()
} #37 0x0000000105d3c6ce in qualisdev ()

qualisdev() doesn't call anything.  Stack definitely hosed.

Nevertheless, it looks like glob.c needs to protect some places where
it manipulates global state.