Thunar NDEBUG and _thunar_assert macros

[Matthew Brush]

On 14-11-07 11:47 AM, Alistair Buxton wrote:
> Hi,
>
> I was browsing the crash reports from errors.ubuntu.com again today
> and I found something interesting in Thunar.
>
> There is a bug report at
> https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1147349
>
> What is happening here is that thunar_file_is_directory is segfaulting
> if file is NULL.
>
> Code: http://git.xfce.org/xfce/thunar/tree/thunar/thunar-file.c#n2544
>
>  From a first look at this function, it's impossible for it to
> segfault. It is two lines, and the first line should return false if
> file is NULL.
>
> But there's a problem, in thunar-private.h:
>
> http://git.xfce.org/xfce/thunar/tree/thunar/thunar-private.h#n28
>
> What this block of code does is turn all those checks into null ops if
> you do a release build.
>
> It looks to me like what has happened here is those macros were
> originally meant for debugging, but later people have relied on them
> to catch errors, not realising they don't work in release mode. So in
> release mode Thunar will just go ahead and use an invalid pointer. I'm
> pretty sure this is the cause of the above segfault, and it can
> probably cause silent memory corruption too, if a pointer is valid but
> the wrong type.
>

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.

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).

Cheers,
Matthew Brush