I have some valgrind and helgrind reports. Note that thunar does not
segfault in valgrind, presumably because valgrind imposes thread
serialisation.
Some dodgy behaviour detected by valgrind memcheck (the default) from
three separate processes:
==27638== Invalid read of size 8
==27638== at 0x7BCF8B4: g_type_check_instance_cast (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==27638== by 0x14B4F9: thunar_icon_factory_clear_pixmap_cache (in
/usr/bin/thunar)
==27638== by 0x143B98: thunar_file_reload (in /usr/bin/thunar)
==27638== by 0x7E37E89: g_main_context_dispatch (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==27638== by 0x7E3822F: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==27638== by 0x7E38551: g_main_loop_run (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==27638== by 0x5E0A586: gtk_main (in
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.29)
==27638== by 0x12B764: main (in /usr/bin/thunar)
==27638== Address 0x14956910 is 0 bytes inside a block of size 120 free'd
==27638== at 0x4C2AEAB: free (vg_replace_malloc.c:530)
==27638== by 0x7BCE5D9: g_type_free_instance (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==27638== by 0xC5E105F: ffi_call_unix64 (in
/usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==27638== by 0xC5E0ACA: ffi_call (in
/usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==27638== by 0x7BABC94: g_cclosure_marshal_generic_va (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==27638== by 0x7BAB173: ??? (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==27638== by 0x7BC5975: g_signal_emit_valist (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==27638== by 0x7BC605E: g_signal_emit (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==27638== by 0x79139D8: ??? (in
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.2)
==27638== by 0x7E37FD6: g_main_context_dispatch (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==27638== by 0x7E3822F: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==27638== by 0x7E38551: g_main_loop_run (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==27638== Block was alloc'd at
==27638== at 0x4C29C4F: malloc (vg_replace_malloc.c:299)
==27638== by 0x7E3D558: g_malloc (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==27638== by 0x7E54742: g_slice_alloc (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==27638== by 0x7E54DDD: g_slice_alloc0 (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==27638== by 0x7BCE2A1: g_type_create_instance (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==27638== by 0x7BB02BA: ??? (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==27638== by 0x7BB1BA0: g_object_newv (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==27638== by 0x7BB24D3: g_object_new (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==27638== by 0x145A00: thunar_file_get (in /usr/bin/thunar)
==27638== by 0x145D81: thunar_file_monitor (in /usr/bin/thunar)
==27638== by 0xC5E105F: ffi_call_unix64 (in
/usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==27638== by 0xC5E0ACA: ffi_call (in
/usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==28312== Syscall param writev(vector[...]) points to uninitialised byte(s)
==28312== at 0x83FB08D: ??? (in /lib/x86_64-linux-gnu/libc-2.21.so)
==28312== by 0xB75C648: ??? (in
/usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==28312== by 0xB75CA3C: ??? (in
/usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==28312== by 0xB75CAC4: xcb_writev (in
/usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==28312== by 0x9210D6D: _XSend (in
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==28312== by 0x9210E48: _XEventsQueued (in
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==28312== by 0x92026C6: XPending (in
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==28312== by 0x637CE0D: ??? (in
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.29)
==28312== by 0x7E3775C: g_main_context_prepare (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==28312== by 0x7E380FA: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==28312== by 0x7E38551: g_main_loop_run (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==28312== by 0x5E0A586: gtk_main (in
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.29)
==28312== Address 0xe487246 is 38 bytes inside a block of size 16,384
alloc'd
==28312== at 0x4C2BC15: calloc (vg_replace_malloc.c:711)
==28312== by 0x9201021: XOpenDisplay (in
/usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==28312== by 0x6373298: gdk_display_open (in
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.29)
==28312== by 0x6342FDE: gdk_display_open_default_libgtk_only (in
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.29)
==28312== by 0x5E09DC7: ??? (in
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.29)
==28312== by 0x7E42D57: g_option_context_parse (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==28312== by 0x5E0A2AA: gtk_init_with_args (in
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.29)
==28312== by 0x12B3D5: main (in /usr/bin/thunar)
==29233== Syscall param access(pathname) points to unaddressable byte(s)
==29233== at 0x83F5917: access (in /lib/x86_64-linux-gnu/libc-2.21.so)
==29233== by 0x7E24166: g_file_test (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==29233== by 0x182915: thunar_thumbnailer_queue_files (in
/usr/bin/thunar)
==29233== by 0x17B544: thunar_standard_view_request_thumbnails_real
(in /usr/bin/thunar)
==29233== by 0x7E388F2: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==29233== by 0x7E37E89: g_main_context_dispatch (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==29233== by 0x7E3822F: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==29233== by 0x7E38551: g_main_loop_run (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==29233== by 0x5E0A586: gtk_main (in
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.29)
==29233== by 0x12B764: main (in /usr/bin/thunar)
==29233== Address 0x0 is not stack'd, malloc'd or (recently) free'd
valgrind helgrind reports a huge number of possible data races. I needed
to use --error-limit=no to get close to where the segfault (without
valgrind) is seen:
valgrind --tool=helgrind --error-limit=no thunar
Here is one that caught my eye. There are thousands of different reports:
==16648== Possible data race during write of size 8 at 0x113552B0 by
thread #5
==16648== Locks held: none
==16648== at 0x181A94: thunar_thumbnail_cache_move_file (in
/usr/bin/thunar)
==16648== by 0x183E2C: thunar_transfer_job_execute (in /usr/bin/thunar)
==16648== by 0x507708C: ??? (in
/usr/lib/x86_64-linux-gnu/libexo-1.so.0.1.0)
==16648== by 0x78816E5: ??? (in
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.2)
==16648== by 0x78A6B3C: ??? (in
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.2)
==16648== by 0x7E6635D: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==16648== by 0x7E659C4: ??? (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==16648== by 0x4C30E76: mythread_wrapper (hg_intercepts.c:389)
==16648== by 0x810B283: start_thread (pthread_create.c:333)
==16648== by 0x840974C: clone (in /lib/x86_64-linux-gnu/libc-2.21.so)
==16648==
==16648== This conflicts with a previous write of size 8 by thread #1
==16648== Locks held: none
==16648== at 0x181A94: thunar_thumbnail_cache_move_file (in
/usr/bin/thunar)
==16648== by 0x142690: thunar_file_move_thumbnail_cache_file (in
/usr/bin/thunar)
==16648== by 0x145D42: thunar_file_monitor (in /usr/bin/thunar)
==16648== by 0xC5E805F: ffi_call_unix64 (in
/usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==16648== by 0xC5E7ACA: ffi_call (in
/usr/lib/x86_64-linux-gnu/libffi.so.6.0.4)
==16648== by 0x7BB2C94: g_cclosure_marshal_generic_va (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==16648== by 0x7BB2173: ??? (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==16648== by 0x7BCC975: g_signal_emit_valist (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==16648== Address 0x113552b0 is 32 bytes inside a block of size 120 alloc'd
==16648== at 0x4C2B06F: malloc (vg_replace_malloc.c:299)
==16648== by 0x7E44558: g_malloc (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==16648== by 0x7E5B742: g_slice_alloc (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==16648== by 0x7E5BDDD: g_slice_alloc0 (in
/lib/x86_64-linux-gnu/libglib-2.0.so.0.4600.2)
==16648== by 0x7BD52A1: g_type_create_instance (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==16648== by 0x7BB72BA: ??? (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==16648== by 0x7BB8BA0: g_object_newv (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==16648== by 0x7BB94D3: g_object_new (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==16648== by 0x1329A0: thunar_application_get_thumbnail_cache (in
/usr/bin/thunar)
==16648== by 0x183B91: thunar_transfer_job_execute (in /usr/bin/thunar)
==16648== by 0x507708C: ??? (in
/usr/lib/x86_64-linux-gnu/libexo-1.so.0.1.0)
==16648== by 0x78816E5: ??? (in
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4600.2)
==16648== Block was alloc'd by thread #5
--
Ben Caradoc-Davies <b...@transient.nz>
Director
Transient Software Limited <http://transient.nz/>
New Zealand
_______________________________________________
Pkg-xfce-devel mailing list
Pkg-xfce-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-xfce-devel
