GNOME Bugzilla – Bug 661172
bluetooth-applet crashed with SIGSEGV in filter_type_func()
Last modified: 2013-04-16 09:15:16 UTC
this report has been filed here: https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/859321 Package: gnome-bluetooth 3.2.0-0ubuntu1 "Trying to browse data on bluetooth device." ".
+ Trace 228706
Thread 1 (Thread 0x7fd1be0f8940 (LWP 2166))
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 654172 ***
This is actually not a duplicate of bug 654172, because the version of Ubuntu includes the patches in bug 654172, but is still succeptible to this issue. It has since been fixed, however.
(In reply to comment #2) > This is actually not a duplicate of bug 654172, because the version of Ubuntu > includes the patches in bug 654172, but is still succeptible to this issue. It > has since been fixed, however. I'd need either a way to reproduce the problem, or assurances that the problem isn't in the humongous app indicator patch.
I hadn't considered that. We have been able to fix the problem by only updating gnome-bluetooth to the latest development package (3.2.1-0ubuntu2), but I'm still investigating and may end up bisecting everything to figure out what fixed it. Since it's fixed I don't think there's anything for you to do here unless it is fixed by one of our distro patches. I'm leaving on NEEDINFO for now. I'll post again I complete analysis.
There is definitely a bug in bluetooth-applet, though it will not be visible to gnome3 users or (i think) to people that have a working bluetooth stack. I think what makes this bug visible is that browsing files on the device fails, which is the current case in Ubuntu. It looks like we have a use of a variable after it's been freed. First let me go through how to reproduce the problem. Select "browse files on device" from the applet, then select a device, then hit the "browse" button on the dialog. A few seconds will go by, and then there is a segfault. (bluetooth-applet:24077): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `BluetoothChooser' (bluetooth-applet:24077): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)' Program received signal SIGSEGV, Segmentation fault. That corresponds to this code, around bluetooth-chooser.c:675: BluetoothChooser *self = BLUETOOTH_CHOOSER (data); BluetoothChooserPrivate *priv = BLUETOOTH_CHOOSER_GET_PRIVATE(self); Subsequently, *priv is dereferenced and the application crashes. Using gdb to figure out what's happening here: Breakpoint 1, bluetooth_chooser_init (self=0x64f5c0) at bluetooth-chooser.c:869 warning: Source file is more recent than executable. 869 { 7: x/2xg 0x64f5c0 0x64f5c0: 0x00000000007cfe30 0x0000000000000001 (gdb) p *self $18 = {parent = {container = {widget = {parent_instance = {g_type_instance = {g_class = 0x7cfe30}, ref_count = 1, qdata = 0x74e942}, priv = 0x64f5f0}, priv = 0x64f660}, priv = 0x64f670}} on initialization, self has ref_count = 1. Then after clicking the "browse" button: Breakpoint 2, filter_func (model=0x73b500, iter=0x7fffffffcef0, data=0x64f5c0) at bluetooth-chooser.c:667 667 { 7: x/2xg 0x64f5c0 0x64f5c0: 0x000000000064fe60 0x0000000000000000 Has ref_count = 0. If you continue from here you'll get the glib messages and the segfault. I haven't looked into where we have "one too many" free() yet. I don't appear to have the appropiate permission to make this UNCONFIRMED.
One solution to this is to make gnome-applet look like the dropdown in gnome-shell. That consists of removing the "Browse files on a device" option and moving the "Send files to device" down with the "Setup new device" field. This bug is also present on gnome-classic.
I tried very hard and couldn't reproduce the bug at the time. I need a sure fire way to reproduce the problem, or a run under valgrind for example, so we can see the first after-free usage.
(In reply to comment #7) > I tried very hard and couldn't reproduce the bug at the time. I need a sure > fire way to reproduce the problem, or a run under valgrind for example, so we > can see the first after-free usage. Hi Bastien. I've been working on other things, but I have enough time to look into this bug further. Is there a specific valgrind test I should run to get the best output? Also, I have one additional anecdote. If the user selects "Motorola Phone" from the applet drop down and uses "browse", this works. From then on, there is no segfault from the browse dialog. If I then log out and back in, and select the browse dialog straight away, the applet crashes.
Run it under valgrind and reproduce the problem, the default settings should show whatever interesting things there are to see.
We never figured out what the problem is. It looks to be resolved with a rebase that we pulled in. Thanks for your help. Please close this bug.
This is still happening in Ubuntu 12.10. You should have some stack traces by now from Ubuntu's crash reporter. Please fix this.
(In reply to comment #11) > This is still happening in Ubuntu 12.10. > > You should have some stack traces by now from Ubuntu's crash reporter. Stack traces are useless as already mentioned.
(In reply to comment #11) > This is still happening in Ubuntu 12.10. > > You should have some stack traces by now from Ubuntu's crash reporter. > > Please fix this. Hi Steve, Our investigation into the problem confirmed that it was fixed in 12.04 and, we assumed, 12.10. If you are still having problems it is a different issue. Please open a new issue in launchpad against 12.10
James, OK, I'll re-open it in another bug report. I took your previous remark: "We never figured out what the problem is", to mean you had *not* confirmed anything -- my mistake, I guess. There will be several more reports, I expect. I just did a clean upgrade to my system, and now gnome bluetooth is broken in one new way, and two old ones. But really, the gnome bluetooth applet is a bug-o-rama -- who's to say *which* bug one is seeing at any given time? Bastien, "stack traces are useless as already mentioned" ??? What ??? Already mentioned where? I don't see any such previous remark in this exchange. Why? I use stack traces regularly! Are you referring to something about this particular application? Or are you impugning the programming capacities of the contributors?