Thunar NDEBUG and _thunar_assert macros

[Nick Schermer]

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.

So the trick is the find the issue and was eventually quite sure it was not
in thunar.

Nick
Op 8 nov. 2014 11:47 schreef "Alistair Buxton" <a.j.buxton at gmail.com>:

> On 8 November 2014 02:36, Matthew Brush <mbrush at codebrainz.ca> wrote:
>
> > It's possible the author of that code actually meant to use one of those
> > debug precondition checks properly, not expecting it to fail (or crash,
> in
> > release mode) unless it was fed a garbage pointer from outside.
>
> Agreed.
>
> > On the bright side, without the checks, it doesn't propagate the error
> > further and allows it to crash in the proper place :)  It'd be
> interesting
> > to see why there are NULLs in the GSequence in the first place. It's
> hard to
> > tell from the backtrace since it happens indirectly in that callback
> > function and I'm not familiar with Thunar's code (or having time to
> > investigate it right now).
>
> The problem is that the segfault is the first crash I've seen that
> allowed be to get some clue to what is going on, and even then it
> isn't helpful for fixing it. I would say that at least 50% of all
> crashes in Xubuntu reported by apport are weird Thunar memory
> corruption bugs, and so far this is the most likely cause I have seen.
>
> Even though this particular error resulted in a segfault, it isn't
> difficult to imagine a situation where a pointer of the wrong type is
> written to. This would silently fail in the debug build, and corrupt
> memory in release. Neither of which is helpful.
>
> The question is what can we do about this? It's quite a big issue,
> _thunar_return_* is used approximately 1600 times in the Thunar source
> code.
>
> --
> Alistair Buxton
> a.j.buxton at gmail.com
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20141108/5f3b6b64/attachment.html>