abrt detected a crash.
Comment: Crashes on startup
Attached file: backtrace
cmdline: /usr/bin/python /usr/bin/blueman-applet
reason: Process was terminated by signal 11
Created attachment 369008 [details]
This is from starting blueman-applet from blueman-1.21-1.fc12.x86_64 (currently in updates-testing)
Thanks for filing this bug report.
How reproducable is this problem?
I've been trying to reproduce this behavior, but haven't managed to see it yet.
If you run it from a terminal, is there any output?
Notes to self: looking at the backtrace, frames 26 and below show a pygtk application starting up.
An event comes in frame 24/25, and is dispatched into pulsecore (frames 23->18; pstream_packet_callback, pa_context_simple_ack_callback) which calls a Python callback (down to frame 15), which invokes python code down to frame 3, where it calls back into native code; whereupon the segfault happens, calling Py_DecRef on some object pointer.
So yesterday it was crashing all the time, now it happens on login (I haven't tried to see if its on each login or only the first for the reboot)
It happens all the time, even with my hardware kill switch on, and on my laptop that removes the BlueTooth adapter from the USB bus entirely, so this should in theory be reproducable for anyone. I don't have another PC to test with, though.
Now it starts on the second run. there's nothing useful in .xsession-errors for the first crash - is there some way of capturing the full console logs that appears if I run it manually from an xterm?
I have another crash that I can upload if you want, but I assume its the same. After manually starting blueman-applet, this is being sent through the new blueman with BT tethering to my iPhone, so it definitely works now(*)
(*) I had to manually run dhclient because NM doesn't recognise the bnap device, but thats a separate bug
Created attachment 369153 [details]
OK, I can reproduce this 100%. Based on the pulseaudio bits in the log, I tried:
1. killall pulseaudio
Second time it works, because pulseaudio is started. It looks like the applet starts up pulseaudio but then tries to use it before its ready, and crashes?
Log attached, but its truncated (presumably python's buffering when redirecting the a file loses the output when it segfaults). I'll play arround and try to get something better when I'm not using bluetooth for my internet connection :)
*** Bug 537080 has been marked as a duplicate of this bug. ***
Created attachment 369206 [details]
This was run with the hardware kill switch enabled (ie no BT USB adapter) after doing |killall pulseaudio|
Thanks for the info.
Looks like a bug in the blueman candidate update package, or, at least, a bad interaction between various components.
I see this is for https://admin.fedoraproject.org/updates/F12/FEDORA-2009-11145 and that you've already reported this there (thanks!)
I just now managed to reproduce this on an i386 F11 box with the F11 version of that update (https://admin.fedoraproject.org/updates/F11/FEDORA-2009-11065 ); I've commented there accordingly.
Segfault seems to be happening in /usr/lib/python2.6/site-packages/blueman/main/PulseAudioUtils.py
def simple_callback(self, handler, function, *args):
def wrapper(context, res, data):
cb = pa_context_index_cb_t(wrapper)
args += (cb, py_object(cb))
(indentation of above mangled by bugzilla, alas)
Created attachment 369224 [details]
Backtrace from blueman-applet from blueman-1.21-1.fc11.i586 triggered by restarting pulseaudio (via killall pulseaudio)
If I change line 173 of /usr/lib/python2.6/site-packages/blueman/main/PulseAudioUtils.py
then the segfault seems to go away. Not yet sure if it's the correct fix.
Adding the additional py_object() wrapper looks like a reasonable way to fix up that code - the ctypes function call is expecting a PyObject* that's a _ctypes.SimpleType, storing a reference to the underlying PyObject*, rather than simply the original PyObject*.
Having said that, does libpulse have python bindings? Doing it all through ctypes is fragile and is likely to break (e.g. if anything changes in the libpulse API, you're going to have to manually update it there, and in every other such user of the API, rather than fixing it in one place).
(I don't have a launchpad account, so I can't send this upstream)
I talked to walmis, the Blueman developer. Blueman 1.21-2 should arrive shortly in the testing repos.
Forgot to add, he's using
To fix the issue, as you suggested, Dave.
blueman-1.21-2.fc11 has been submitted as an update for Fedora 11.
blueman-1.21-2.fc12 has been submitted as an update for Fedora 12.
Fixes the crash - thanks a lot for the quick response. Unfortunately the update breaks connecting to the iPhone entirely, but thats a separate bug...
(In reply to comment #19)
> Fixes the crash - thanks a lot for the quick response. Unfortunately the update
> breaks connecting to the iPhone entirely, but thats a separate bug...
(for posterity: the iPhone connectivity regression was bug 537089)
blueman-1.21-2.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update blueman'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-11519
blueman-1.21-2.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update blueman'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-11594
blueman-1.21-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 542995 has been marked as a duplicate of this bug. ***
blueman-1.21-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 576116 has been marked as a duplicate of this bug. ***