Thunar NDEBUG and _thunar_assert macros

Alistair Buxton a.j.buxton at
Sun Nov 9 10:43:17 CET 2014

On 8 November 2014 16:57, Nick Schermer <nick at> wrote:
> I've seen the Ubuntu bug reports about this and also looked through the
> problem. The assert would not help in this case and I'll try to explain why.
> The null error is caused by an memory corruption or refcount issue (file has
> already been freed, but used in another thread). If you enable assert you
> will never catch the issue because writing in the console or the check
> macros (thise use a hashtable for type lookup in the main thread) delays the
> function long enough to finish using the file in the other thread. And it
> will go wrong elsewhere.
> I was able to reproduce the bug in some case and with a normal
> g_return_if_fail it did not properly catch the free.
> Also in gdb the crash did not occur because the thread order was different
> or slower.

This sounds like it could be related to finalization sequence.

For example:

Shouldn't the file monitor signal be disconnected before freeing the
rows? The monitor callback will attempt to use them.

Also, shouldn't the monitor be unref'd in dispose?

GObject docs: "the dispose handler is supposed to release all
references to other member objects"

Alistair Buxton
a.j.buxton at

More information about the Xfce4-dev mailing list