After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 762763 - mutter crash with MetaStartupNotificationSequenceX11 and libstartup-notification-1.so
mutter crash with MetaStartupNotificationSequenceX11 and libstartup-notificat...
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
: 763193 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-02-27 05:09 UTC by bluescreen_avenger
Modified: 2016-03-07 12:57 UTC
See Also:
GNOME target: 3.20
GNOME version: ---


Attachments
startup-notification: Ensure provided timestamp is always a 64 bit integer (2.08 KB, patch)
2016-03-06 04:10 UTC, Jonas Ådahl
committed Details | Review

Description bluescreen_avenger 2016-02-27 05:09:13 UTC
It seems that mutter crashes with libstartup-notification. I tried building GTK, clutter, cogl to master.  I am using the libstartup-notification with Debian Testing

(gnome-shell:21049): GLib-GObject-CRITICAL **: g_object_new_valist: object class 'MetaStartupNotificationSequenceX11' has no property named '\u0004'

Program received signal SIGSEGV, Segmentation fault.
0xb7227f44 in sn_startup_sequence_ref ()
   from /usr/lib/i386-linux-gnu/libstartup-notification-1.so.0
(gdb) bt
  • #0 sn_startup_sequence_ref
    from /usr/lib/i386-linux-gnu/libstartup-notification-1.so.0
  • #1 meta_startup_notification_sequence_x11_set_property
    at core/startup-notification.c line 326
  • #2 object_set_property
    at gobject.c line 1421
  • #3 g_object_new_internal
    at gobject.c line 1815
  • #4 g_object_new_valist
    at gobject.c line 2040
  • #5 g_object_new
    at gobject.c line 1624
  • #6 meta_startup_notification_sequence_x11_new
    at core/startup-notification.c line 388
  • #7 meta_startup_notification_sn_event
    at core/startup-notification.c line 627
  • #8 ??
    from /usr/lib/i386-linux-gnu/libstartup-notification-1.so.0
  • #9 sn_list_foreach
    from /usr/lib/i386-linux-gnu/libstartup-notification-1.so.0
  • #10 ??
    from /usr/lib/i386-linux-gnu/libstartup-notification-1.so.0
  • #11 sn_list_foreach
    from /usr/lib/i386-linux-gnu/libstartup-notification-1.so.0
  • #12 ??
    from /usr/lib/i386-linux-gnu/libstartup-notification-1.so.0
  • #13 ??
    from /usr/lib/i386-linux-gnu/libstartup-notification-1.so.0
  • #14 sn_list_foreach
    from /usr/lib/i386-linux-gnu/libstartup-notification-1.so.0
  • #15 sn_internal_xmessage_process_client_message
    from /usr/lib/i386-linux-gnu/libstartup-notification-1.so.0
  • #16 sn_display_process_event
    from /usr/lib/i386-linux-gnu/libstartup-notification-1.so.0
  • #17 meta_startup_notification_handle_xevent
    at core/startup-notification.c line 741
  • #18 meta_display_handle_xevent
    at x11/events.c line 1674
  • #19 xevent_filter
    at x11/events.c line 1785
  • #20 gdk_event_apply_filters
    at gdkeventsource.c line 81
  • #21 gdk_event_source_translate_event
    at gdkeventsource.c line 200
  • #22 _gdk_x11_display_queue_events
    at gdkeventsource.c line 343
  • #23 gdk_display_get_event
    at gdkdisplay.c line 392
  • #24 gdk_event_source_dispatch
    at gdkeventsource.c line 365
  • #25 g_main_dispatch
    at gmain.c line 3154
  • #26 g_main_context_dispatch
    at gmain.c line 3769
  • #27 g_main_context_iterate
    at gmain.c line 3840
  • #28 g_main_loop_run
    at gmain.c line 4034
  • #29 meta_run
    at core/main.c line 537
  • #30 main
    at main.c line 471

Comment 1 Jasper St. Pierre (not reading bugmail) 2016-02-27 05:25:13 UTC
https://git.gnome.org/browse/mutter/tree/src/core/startup-notification.c#n390

This isn't guaranteed to return a gint64, because libsn unhelpfully uses "long" (IIRC), so it's reading the wrong data because varargs.
Comment 2 bluescreen_avenger 2016-02-27 18:46:53 UTC
Mutter was compiled with 32 bits... I could try to see if this happens on the 64 bit version?
Comment 3 bluescreen_avenger 2016-03-02 04:05:28 UTC
let me know if I need to provide any more information? This seems to happen every time I open a new window
Comment 4 bluescreen_avenger 2016-03-06 03:27:26 UTC
More testing. It seems to only affect it on 32 bit systems. Also, it's not as widespread as I thought, seems to happen when calling the background/resolution config screens of the desktop context menu
Comment 5 Jonas Ådahl 2016-03-06 04:10:17 UTC
Created attachment 323181 [details] [review]
startup-notification: Ensure provided timestamp is always a 64 bit integer

The libsn API provides its timestamps in the "Time" X11 type, which is
usually is a typedef for "unsigned long". The type of the "timestamp"
parameter of StartupNotificationSequence is a signed 64 bit integer.
When building on an architecture where a "unsigned long" is not 64 bit,
we'd then pass a 32 bit unsigned integer via a va_list where a signed 64
bit integer is expected causing va_arg to read past the passed 32 bit
unsigned integer.

Fix this by ensuring that we always pass the expected type via the
va_list. Also change the internal timestamp type from time_t (which
size is undefined) to gint64, to avoid any potential overflow issues.
Comment 6 Jonas Ådahl 2016-03-06 04:11:25 UTC
(In reply to bluescreen_avenger from comment #4)
> More testing. It seems to only affect it on 32 bit systems. Also, it's not
> as widespread as I thought, seems to happen when calling the
> background/resolution config screens of the desktop context menu

Could you test the attached patch? It should fix the issue, if the only reason is what Jasper described above, but I have not tested it myself.
Comment 7 bluescreen_avenger 2016-03-06 16:43:57 UTC
It works!
Comment 8 Rui Matos 2016-03-06 17:12:26 UTC
Review of attachment 323181 [details] [review]:

Looks good
Comment 9 Jonas Ådahl 2016-03-07 03:22:04 UTC
Attachment 323181 [details] pushed as 0882bce - startup-notification: Ensure provided timestamp is always a 64 bit integer
Comment 10 Rui Matos 2016-03-07 12:57:02 UTC
*** Bug 763193 has been marked as a duplicate of this bug. ***