[ Solved, Tanu is on the ball once again! Ignore the pointless patch (it truely is pointless) ] See below if you want more info. 'Twas brillig, and Tanu Kaskinen at 09/01/14 12:50 did gyre and gimble: > On Thu, 2014-01-09 at 10:07 +0000, Colin Guthrie wrote: >> Hi, >> >> In order to get Bluetooth support (at least A2DP) I've been tracking the >> 5.0 release for Mageia (it's generally an unfortunate situation but such >> is life). >> >> Sadly there appears to be some ABI breakage introduced related to card >> profiles. >> >> This is purportedly fixed by the below commit but I think there are >> still issues. >> >> I've had crashes reported in both KDE's kcm_phonon (the bits which which >> I wrote) and pavucontrol directly, both related to updating card info. >> It seems invalid string information is passed in to string compare >> functions and they crash. >> >> https://bugs.mageia.org/show_bug.cgi?id=12155 > > Here's a snippet of the pavucontrol backtrace: > > Program received signal SIGSEGV, Segmentation fault. > __strcmp_ssse3 () at ../sysdeps/i386/i686/multiarch/strcmp-ssse3.S:240 > 240 movzbl (%eax), %ecx > (gdb) bt > #0 __strcmp_ssse3 () at ../sysdeps/i386/i686/multiarch/strcmp-ssse3.S:240 > #1 0x0806daa0 in operator() (this=0xbfffe80c, lhs=..., lhs=..., rhs=..., > rhs=...) at mainwindow.cc:43 > #2 _M_get_insert_unique_pos (__k=..., this=0xbfffe80c) > at /usr/include/c++/4.8.2/bits/stl_tree.h:1324 > #3 std::_Rb_tree<pa_card_profile_info, pa_card_profile_info, std::_Identity<pa_card_profile_info>, profile_prio_compare, std::allocator<pa_card_profile_info> >::_M_insert_unique (this=0xbfffe80c, __v=...) > at /usr/include/c++/4.8.2/bits/stl_tree.h:1377 > #4 0x08069947 in insert (__x=..., this=0xbfffe80c) > at /usr/include/c++/4.8.2/bits/stl_set.h:463 > #5 MainWindow::updateCard (this=0x822e688, info=...) at mainwindow.cc:319 > #6 0xb7422e33 in context_get_card_info_callback (pd=pd at entry=0x8133208, > command=command at entry=2, tag=tag at entry=5, t=t at entry=0x825f930, > userdata=userdata at entry=0x82c94f8) at pulse/introspect.c:971 > > One of the parameters of std::_Rb_tree is > std::allocator<pa_card_profile_info>, and that looks like the data > structure allocates pa_card_profile_info objects. That's not safe. It > looks like pavucontrol is buggy. Just out of interest, why is that not safe? Is allocating a struct not safe in a set? Various bits I've read seem to suggest this isn't a problem. > void MainWindow::updateCard(const pa_card_info &info) { > ... > std::set<pa_card_profile_info,profile_prio_compare> profile_priorities; > > The set should contain pointers, not whole profile info objects. Using pointers seems somewhat counter-intuitive. By default the ordering semantics would be on the pointer address which is pretty arbitrary (although I accept that it's likely equally arbitrary with structs without overloading the < operator, which we don't do anyway) > Hmm... but pa_card_profile_info hasn't been modified in the current > master compared to v4.0, so if pavucontrol was compiled against libpulse > from v4.0, there should be no problem. Is it possible that pavucontrol > was compiled against some earlier git snapshot in Mageia that had the > available flag added to pa_card_profile_info, and now that the flag was > removed, pavucontrol broke? Yeah it was complied Sat 19 Oct 2013 00:02:08 BST, at which point the PA itself was a 5.0 snapshot at f81e3e1d7852c05b4b737ac7dac4db95798f0117. So thinking about it a bit more, I can see the problem and yes, you got it bang on as f81e3e1d7852c05b4b737ac7dac4db95798f0117 included the ABI break but not the fix! D'oh!! Sorry for noise! Thanks Tanu! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
