[Thunar-dev] Experimental Thunar Trash tarball

[Benedikt Meurer]

Björn Martensen wrote:
>>>>You already spotted the invalid free()'s earlier. Now you just need to
>>>>make Thunar crash, i.e. run Thunar with
>>>>
>>>>export G_SLICE=always-malloc
>>>>export MALLOC_CHECK_=2
>>>>
>>>>and be sure to terminate any running instance first (Thunar -q).
>>>
>>>http://bugzilla.gnome.org/show_bug.cgi?id=348953
>>>If I wrote anything wrong please correct it
>>
>>Err, post the backtrace here first. As this one looks more like a
>>problem in Thunar (unlike bug #2028).
> 
> sorry. here you go..
> 
>>Stack trace:
>>(gdb) bt
>>#0  0xffffe410 in __kernel_vsyscall ()
>>#1  0xb78145a1 in raise () from /lib/libc.so.6
>>#2  0xb7815c09 in abort () from /lib/libc.so.6
>>#3  0xb784ead8 in malloc_printerr () from /lib/libc.so.6
>>#4  0xb78500a5 in free () from /lib/libc.so.6
>>#5  0xb7950bc1 in g_free () from /usr/lib/libglib-2.0.so.0
>>#6  0xb796101c in g_slice_free1 () from /usr/lib/libglib-2.0.so.0
>>#7  0xb7f42b52 in thunar_vfs_monitor_remove ()
>>   from /opt/xfce4/lib/libthunar-vfs-1.so.2
>>#8  0x08077902 in thunar_folder_finalize (object=0x83ba638)
>>    at thunar-folder.c:247

Thunar is build with --enable-debug=full? Because the case that the
handle was already freed would have been detected by
thunar_vfs_monitor_remove() then. So the only left-over option is memory
corruption.

What is printed on the console right before the crash?

> Björn

Benedikt