Bug#708559: Seeing the same issue with chrome
Tobias Diedrich
tobiasdiedrich at gmail.com
Sun May 31 11:25:11 UTC 2015
On Sun, 31 May 2015 01:33:17 +0200 Tobias Diedrich <tobiasdiedrich at gmail.com>
wrote:
> I'm seeing the same issue triggered by using dwm and chrome:
[...]
> I suspect that this is a nullpointer dereference of icon->priv?
[...]
More likely use-after-free since priv seems to be allocated together with
the main object according to gtk docs (though priv is 0 in the crash trace,
I presume that dispose nulls it out):
(gdb) bt full
#0 0x00007ffff282d616 in gtk_tray_icon_manager_filter
(xevent=0x7fffffffd9b0, event=<optimized out>, user_data=0x1fc1e1487ea0) at
/build/gtk+2.0-czQfyJ/gtk+2.0-2.24.25/gtk/gtktrayicon-x11.c:400
icon = 0x1fc1e1487ea0
xev = 0x7fffffffd9b0
[...]
(gdb) print icon
$1 = 0x1fc1e1487ea0
(gdb) print *icon
$2 = {parent_instance = {window = {bin = {container = {widget = {object =
{parent_instance = {g_type_instance = {g_class = 0xf}, ref_count = 0, qdata
= 0x0}, flags = 0}, private_flags = 0, state = 0 '\000', saved_state = 0
'\000', name = 0xffffffff00000000 <error: Cannot access memory at address
0xffffffff00000000>,~
style = 0xffff, requisition = {width = 2010019790, height =
30670}, allocation = {x = 0, y = -353703190, width = 60138, height = 0},
window = 0xd36cd36cd36c, parent = 0x-e090e0a00000000}, focus_child =
0xf1f6, border_width = 29298, need_resize = 1, resize_mode = 3,
reallocate_redraws = 1,~
has_focus_chain = 1}, child = 0x-20d420d500000000}, title =
0xdf2b <error: Cannot access memory at address 0xdf2b>, wmclass_name = 0x0,
wmclass_class = 0x0, wm_role = 0x0, focus_widget = 0x0, default_widget =
0x-100000000, transient_parent = 0xffff, geometry_info = 0x7fff7fff7fff,
frame = 0x-100000000,~
group = 0xffff, configure_request_count = 24541, allow_shrink = 1,
allow_grow = 0, configure_notify_received = 1, need_default_position = 1,
need_default_size = 0, position = 3, type = 15, has_user_ref_count = 0,
has_focus = 0, modal = 0, destroy_with_parent = 1, has_frame = 1,
iconify_initially = 0,~
stick_initially = 0, maximize_initially = 1, decorated = 0, type_hint
= 1, gravity = 2, is_active = 0, has_toplevel_focus = 1, frame_left = 0,
frame_top = 3941264106, frame_right = 60138, frame_bottom = 0,
keys_changed_handler = 2678026866, mnemonic_modifier = 53199, screen =
0x-ccd0cce00000000},~
socket_window = 0x10000f332, modality_window = 0x1, modality_group =
0x1fc1e9a8b410, grabbed_keys = 0x0, same_app = 0}, priv = 0x0}
(gdb)
Looking at the code it is supposed to remove
the gtk_tray_icon_manager_filter before disposing the object, however it
seems possible that:
1) Either gdk_window_remove_filter is called on the wrong window as the
window argument is looked up anew
using gdk_window_lookup_for_display/gdk_screen_get_root_window and I don't
know if gdk guarantees that to be the same result
2) Or it's a threading issue and the filter is invoked on a different
thread than the dispose call and they race (since there doesn't seem to be
locking).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20150531/244cdc7b/attachment.html>
More information about the pkg-gnome-maintainers
mailing list