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 r...@thoryk.com r...@tliquest.net
