* * * * *
It's not even a Heisenbug
I don't think it's a case of one thread releasing a mutex locked by another
thread [1].
Whatever the bug, I can reproduce it rather consistently and every crash has
always been along the same call chain. The mechanism used to trigger the
problematic call chain is a way to work around a deficiency in POSIX (which
I'm sure the original author of said mechanism would say stands for “Piece of
XXXX In eXecution”)—not that I blame the original author, Unix and threads
don't really mix that well (but then in my opinion, if it wasn't in Unix
Version 7 [2], it's not supported well or has a horrible interface—threads,
networking, removable storage, graphical user interfaces, all have … issues
under Unix).
But as of now, I've yet to figure out the actual root cause of the assert:
> tpp.c:63: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= __sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)' failed.
>
Every source I've found on the web with that bug states it has to do with an
uninitialized mutex [3] attribute. The code isn't using mutex attributes, and
even when I added code to use a mutex attribute (initialized!) it still
asserts. Sigh.
And the even weirder thing is—I don't think the component that's crashing is
even being used by what I'm testing! See, the component I'm testing, E, makes
a service request to T. T requires that service X (the one that is crashing)
to be running, but the requests from E shouldn't cause T to make a request to
X. X just sits there and periodically, logs a bunch of stats that basically
show it's not doing a whole lot of work.
I got nothing.
[1]
gopher://gopher.conman.org/0Phlog:2015/06/17.1
[2]
https://en.wikipedia.org/wiki/Version_7_Unix
[3]
https://en.wikipedia.org/wiki/Mutual_exclusion
Email author at
[email protected]
