Bug#515946: libxi6 2:1.2.0-2 makes iceweasel and midori crash
On 2009-05-27 12:16:23 +0200, Julien Cristau wrote:
> On Mon, May 25, 2009 at 16:52:50 +0200, Vincent Lefevre wrote:
> > What information do you need? Would a test under valgrind be useful?
> >
> I guess that's worth a try.
Here's an example with midori 0.1.4-1 (as it is light that iceweasel).
The crash is immediate (I don't have to do anything).
$ valgrind midori
==10974== Memcheck, a memory error detector.
==10974== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==10974== Using LibVEX rev 1884, a library for dynamic binary translation.
==10974== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==10974== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework.
==10974== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==10974== For more details, rerun with: -v
==10974==
==10974== Invalid read of size 8
==10974== at 0x58BD854: _gdk_x11_screen_process_owner_change (gdkscreen-x11.c:1124)
==10974== by 0x58B13E3: gdk_event_translate (gdkevents-x11.c:2093)
==10974== by 0x58B18B6: _gdk_events_queue (gdkevents-x11.c:2298)
==10974== by 0x58B1C8D: gdk_event_dispatch (gdkevents-x11.c:2358)
==10974== by 0x7895F79: g_main_context_dispatch (gmain.c:1814)
==10974== by 0x789963F: g_main_context_iterate (gmain.c:2448)
==10974== by 0x7899B0C: g_main_loop_run (gmain.c:2656)
==10974== by 0x5323B33: gtk_dialog_run (gtkdialog.c:1090)
==10974== by 0x41D652: main (in /usr/bin/midori)
==10974== Address 0x338 is not stack'd, malloc'd or (recently) free'd
==10974==
==10974== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==10974== Access not within mapped region at address 0x338
==10974== at 0x58BD854: _gdk_x11_screen_process_owner_change (gdkscreen-x11.c:1124)
==10974== by 0x58B13E3: gdk_event_translate (gdkevents-x11.c:2093)
==10974== by 0x58B18B6: _gdk_events_queue (gdkevents-x11.c:2298)
==10974== by 0x58B1C8D: gdk_event_dispatch (gdkevents-x11.c:2358)
==10974== by 0x7895F79: g_main_context_dispatch (gmain.c:1814)
==10974== by 0x789963F: g_main_context_iterate (gmain.c:2448)
==10974== by 0x7899B0C: g_main_loop_run (gmain.c:2656)
==10974== by 0x5323B33: gtk_dialog_run (gtkdialog.c:1090)
==10974== by 0x41D652: main (in /usr/bin/midori)
==10974== If you believe this happened as a result of a stack overflow in your
==10974== program's main thread (unlikely but possible), you can try to increase
==10974== the size of the main thread stack using the --main-stacksize= flag.
==10974== The main thread stack size used in this run was 8388608.
==10974==
==10974== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 13 from 2)
==10974== malloc/free: in use at exit: 1,195,307 bytes in 12,078 blocks.
==10974== malloc/free: 38,284 allocs, 26,206 frees, 3,911,189 bytes allocated.
==10974== For counts of detected errors, rerun with: -v
==10974== searching for pointers to 12,078 not-freed blocks.
==10974== checked 9,009,056 bytes.
==10974==
==10974== LEAK SUMMARY:
==10974== definitely lost: 15,762 bytes in 341 blocks.
==10974== possibly lost: 144,280 bytes in 178 blocks.
==10974== still reachable: 1,035,265 bytes in 11,559 blocks.
==10974== suppressed: 0 bytes in 0 blocks.
==10974== Rerun with --leak-check=full to see details of leaked memory.
zsh: segmentation fault valgrind midori
And the backtrace of previous execution (without valgrind):
vin:~> gdb =midori core
GNU gdb 6.8-debian
[...]
Core was generated by `midori'.
Program terminated with signal 11, Segmentation fault.
[New process 10943]
#0 _gdk_x11_screen_process_owner_change (screen=0x0, event=0x7fffe53b6900)
at /scratch/build-area/gtk+2.0-2.16.1/gdk/x11/gdkscreen-x11.c:1124
1124 /scratch/build-area/gtk+2.0-2.16.1/gdk/x11/gdkscreen-x11.c: No such file or directory.
in /scratch/build-area/gtk+2.0-2.16.1/gdk/x11/gdkscreen-x11.c
(gdb) bt
#0 _gdk_x11_screen_process_owner_change (screen=0x0, event=0x7fffe53b6900)
at /scratch/build-area/gtk+2.0-2.16.1/gdk/x11/gdkscreen-x11.c:1124
#1 0x00007feadc5103e4 in gdk_event_translate (display=0x1bb10a0,
event=0x1c27ea0, xevent=0x7fffe53b6900, return_exposes=0)
at /scratch/build-area/gtk+2.0-2.16.1/gdk/x11/gdkevents-x11.c:2093
#2 0x00007feadc5108b7 in _gdk_events_queue (display=0x1bb10a0)
at /scratch/build-area/gtk+2.0-2.16.1/gdk/x11/gdkevents-x11.c:2298
#3 0x00007feadc510c8e in gdk_event_dispatch (source=<value optimized out>,
callback=0x7fffe53b6900, user_data=0x1bb10a0)
at /scratch/build-area/gtk+2.0-2.16.1/gdk/x11/gdkevents-x11.c:2358
#4 0x00007feada4dbf7a in IA__g_main_context_dispatch (context=0x1bbd400)
at /tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gmain.c:1814
#5 0x00007feada4df640 in g_main_context_iterate (context=0x1bbd400, block=1,
dispatch=1, self=<value optimized out>)
at /tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gmain.c:2448
#6 0x00007feada4dfb0d in IA__g_main_loop_run (loop=0x1ccfed0)
at /tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gmain.c:2656
#7 0x00007feadc81eb34 in IA__gtk_dialog_run (dialog=0x1bff050)
at /scratch/build-area/gtk+2.0-2.16.1/gtk/gtkdialog.c:1090
#8 0x000000000041d653 in main ()
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Reply to: