The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Thursday, June 18, 2015

It's not even a Heisenbug

I don't think it's a case of one thread releasing a mutex locked by another thread.

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, 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 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.

Obligatory Picture

[The future's so bright, I gotta wear shades]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.