segmentation fault on SIGINT

Bug #956416 reported by Pim Vullers on 2012-03-15
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Granite
Fix Released
High
Unassigned
Pantheon Wallpaper
Invalid
Undecided
Unassigned
Slingshot
Invalid
Undecided
Unassigned
Wingpanel
Invalid
Undecided
Unassigned

Bug Description

To test slingshot I start it from the terminal. When I then want to end it I press CTRL-C to send the kill command. However, when I do this the application segfaults:

pim@chaos ~ $ slingshot
[INFO 21:28:13.078155] [Application:74] Slingshot version: 0.6
[INFO 21:28:13.078356] [Application:76] Kernel version: 3.2.11-gentoo
[DEBUG 21:28:13.099927] [Gtk] Connecting to session manager
[DEBUG 21:28:13.307620] [SlingshotView:110] In setup_ui ()
[DEBUG 21:28:13.335858] [SlingshotView:172] Ui setup completed
[DEBUG 21:28:13.360687] [SlingshotView:104] Apps loaded
[DEBUG 21:28:13.360796] [SlingshotView:239] Repositioning
^C[WARN 21:28:15.471771] [Application:114] Caught signal (2), exiting
Segmentation fault
pim@chaos ~ $

To find out whether this was a slingshot or granite issue I also tested scratch and wingpanel, they both also segfault when killed, either by CTRL-C or the kill command.

So I think this is some granite issue, although I do not know what causes it... the applications do receive the signal, but then cause a segmentation fault.

Pim Vullers (pimvullers) wrote :
Download full text (4.3 KiB)

I am no hero with gdb, but this is what I got. Looks like a null pointer is dereferenced during cleanup.

pim@chaos ~ $ gdb wingpanel
GNU gdb (Gentoo 7.4 p1) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /usr/bin/wingpanel...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/bin/wingpanel
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[INFO 21:35:09.582108] [Application:74] Wingpanel version: 0.3.0
[INFO 21:35:09.582274] [Application:76] Kernel version: 3.2.11-gentoo
[New Thread 0x7fffec81f700 (LWP 25979)]
[New Thread 0x7fffe7fff700 (LWP 25980)]
[New Thread 0x7fffe492e700 (LWP 25981)]
[FATAL 21:35:09.763279] [GLib] g_error_free: assertion `error != NULL' failed
[FATAL 21:35:09.763389] Wingpanel will not function properly.
[WARN 21:35:09.790248] [libnotify] Failed to connect to proxy
[WARN 21:35:09.805711] [Indicator-Datetime] Unable to read timezone file '/etc/timezone': Failed to open file '/etc/timezone': No such file or directory
[WARN 21:35:09.807319] [libindicator] IndicatorObject class does not have an accessible description.
[WARN 21:35:09.807845] [libindicator] IndicatorObject class does not have an accessible description.
[WARN 21:35:09.814648] [Indicator-Datetime] Unable to read timezone file '/etc/timezone': Failed to open file '/etc/timezone': No such file or directory
[WARN 21:35:09.822830] [Indicator-Datetime] Unable to read timezone file '/etc/timezone': Failed to open file '/etc/timezone': No such file or directory
[WARN 21:35:09.847811] [Panel:285] Panel Height: 28
[WARN 21:35:09.874730] [Indicator-Datetime] Guessed wrong. We thought the max would be 32 but we're now at 33
Error getting devices: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `org.gnome.SettingsDaemon.Power' on object at path /org/gnome/SettingsDaemon/Power
[FATAL 21:35:09.892193] [IDO] ido_calendar_menu_item_set_date: assertion `IDO_IS_CALENDAR_MENU_ITEM(menuitem)' failed
[FATAL 21:35:09.892244] Wingpanel will not function properly.
[WARN 21:35:09.901201] [Gtk] Failed to set text from markup due to error parsing markup: Error on line 1: Entity did not end with a semicolon; most likely you used an ampersand character without intending to start an entity - escape ampersand as &amp;
[WARN 21:35:09.901331] [Gtk] Failed to set text from markup due to error parsing markup: Error on line 1: Entity did not end with a semicolon; most likely you used an ampersand character without intending to start an entity - escape ampersand as &amp;
[WARN 21:35:09.901563] [Gtk] Failed to set text from markup due to error parsing markup: Error on line 1: Entity did not end with a semicolon; most likely you used an ampersand character without intending to start an entity - escape amper...

Read more...

Yes, I can confirm that with Pantheon Wallpaper. Looks like Granite is the source then.

summary: - segmentation fault when granite app gets killed
+ segmentation fault on SIGINT

Marked Wallpaper's bug as duplicate of this one.

OH MY! My Apport hooks worked!

I can reproduce this with Wingpanel too.

Pim Vullers (pimvullers) wrote :

The relevant piece of code, as far as I can see is this:

protected static void sig_handler (int sig) {
    warning ("Caught signal (%d), exiting", sig);
    Granite.app.quit_mainloop ();
}

The warning still gets printed, but then it goes wrong.
- For one it uses the deprecated Granite.app static variable.
- quit_mainloop is a virtual function according to valadoc, so I guess this is the nullpointer which gets dereferenced

It seems that the correct way to end would be to use Gtk.main_quit(), see http://www.valadoc.org/gtk+-3.0/Gtk.main_quit.html

Thanks for your fix, I've just applied it to the trunk :)

  status fixcommitted
  importance high

Le 16/03/2012 16:01, Pim Vullers a écrit :
> The relevant piece of code, as far as I can see is this:
>
> protected static void sig_handler (int sig) {
> warning ("Caught signal (%d), exiting", sig);
> Granite.app.quit_mainloop ();
> }
>
> The warning still gets printed, but then it goes wrong.
> - For one it uses the deprecated Granite.app static variable.
> - quit_mainloop is a virtual function according to valadoc, so I guess this is the nullpointer which gets dereferenced
>
> It seems that the correct way to end would be to use Gtk.main_quit(),
> see http://www.valadoc.org/gtk+-3.0/Gtk.main_quit.html
>

Changed in granite:
importance: Undecided → High
status: New → Fix Committed
Pim Vullers (pimvullers) wrote :

Unfortunately this still does not solve the issue. It even causes an error message since slingshot does not have a gtk main loop.

Changed in granite:
status: Fix Committed → Confirmed
Pim Vullers (pimvullers) wrote :

The linked branch provides an attempt to improve the current implementation. But it is still tricky (wingpanel for example still segfaults).

The problem is that in granite we do not know how the application using it is structured.

For example, in Slingshot there is no Gtk mainloop present (Gtk.main_quit() causes an error because of a failed assertion). It should be terminated by destroying the window. This worked fine a number of times, but I also faced a run in which my terminal is spammed with the following messages:

[FATAL 17:32:32.473797] [GLib-GObject] g_object_ref: assertion `G_IS_OBJECT (object)' failed
[FATAL 17:32:32.473856] Slingshot will not function properly.
[FATAL 17:32:32.473929] [Gtk] gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed
[FATAL 17:32:32.473985] Slingshot will not function properly.

So I guess we need a check on the result of the get_windows call.

Furthermore, wingpanel still did not terminate :-(.

Pim Vullers (pimvullers) wrote :

The question is whether granite, as a library, should catch these signals and act upon them. Does anybody recall why this was added in the first place?

(As a side note, I just disabled the sig_handler and I did not have any segfault. I do not know what handles the signal now. Gtk?)

xapantu (xapantu) wrote :

Ok, having a signal handler to print debug messages is not really
useful. Let's remove it...

Le vendredi 16 mars 2012 à 16:49 +0000, Pim Vullers a écrit :
> The question is whether granite, as a library, should catch these
> signals and act upon them. Does anybody recall why this was added in the
> first place?
>
> (As a side note, I just disabled the sig_handler and I did not have any
> segfault. I do not know what handles the signal now. Gtk?)
>

xapantu (xapantu) wrote :

Hum, in fact, we can let the functions: it may be handy (and it won't
break api) if someone wants to implement one of this signal, but we
shouldn't do anything in it.

Le vendredi 16 mars 2012 à 16:49 +0000, Pim Vullers a écrit :
> The question is whether granite, as a library, should catch these
> signals and act upon them. Does anybody recall why this was added in the
> first place?
>
> (As a side note, I just disabled the sig_handler and I did not have any
> segfault. I do not know what handles the signal now. Gtk?)
>

Changed in pantheon-wallpaper:
status: New → Invalid
Changed in slingshot:
status: New → Invalid
Changed in wingpanel:
status: New → Invalid

GTK probably sets default signal handlers, because all GTK apps I tried don't react to SIGSTP, so I had to freeze them with SIGSTOP

"it may be handy (and it won't break api) if someone wants to implement one of this signal, but we shouldn't do anything in it."
So apps without a custom handler for SIGINT will simply ignore it? Not good.

Pim Vullers (pimvullers) wrote :

No they do not ignore it. The apps still get killed when I did not set
the signal handler in the constructor. So under the hood something still
takes care of this.

--
Pim Vullers
Heerstraat 29 / 5953 GE Reuver
<email address hidden>

Right now apps ignore SIGINT instead of crashing.

Changed in granite:
status: Confirmed → Fix Committed
Daniel Fore (danrabbit) on 2012-05-22
Changed in granite:
milestone: none → 0.1.1
Changed in granite:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers