Thunar NDEBUG and _thunar_assert macros

[Alistair Buxton]

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