Bug#994969: jackd2: segfaults after today's upgrade of other Debian testing packages

[Ryan Thoryk]

I posted this to the upstream bug report:

---

After debugging glib for a while, I might've found the issue.  According 
to the documentation of g_quark_from_static_string(), that function 
shouldn't be used to initialize a global variable, but that's how it's 
being used in the crash location in glibmm.

As part of doing symbol checks, Jack loads and unloads the firewire 
module a number of times, that has the glibmm dependency.  Then it loads 
the module normally.  Glibmm initializes each load, it shows the glib 
functions being called each time.  Since the glibmm initialization uses 
the static_string function, glib stores the pointer to the static string 
inside it's hash table and creates a new gquark (the doc says a gquark 
object creation at this stage is too early).  What should be happening, 
is that due to the module unloads, previously stored string references 
become invalid in the hash table, causing a segfault when doing an 
strcmp, the function doc says to not use that function if you're going 
to unload the module.  The hash table's address itself remains the same 
during all of the loads and unloads, showing that it's not being 
unloaded.  The g_quark_from_string() function works, because it creates 
copies of the strings instead, so it's unload-safe.

Unlike what we thought of before, the string that glibmm passes to the 
glib function remains valid all the way to the crash, the culprit is 
that strcmp compares against a pointer to invalid memory that comes from 
the glib hash table.

-- 
Ryan Thoryk
ryan at thoryk.com
ryan at tliquest.net