Bug#840430: glib2.0: segfaults in nemo when opening files from the desktop

[Jason Crain]

On Wed, Oct 12, 2016 at 10:18:53AM +0900, Norbert Preining wrote:
> Hi Jason,
> 
> > It's a little bit suspicious that in frame 1, the _object pointer is
> > invalid (0x2).  Anyway, the debug packages for gtk are now automatic
> 
> Hmm, I retried, and now a get a different backtrace. It segfaults
> at 100% of instances, but it seems always in different regions:
> (gdb) bt
> #0  0x00007f4e6dd5fb4e in g_slice_free1 (tmem=<optimized out>, mem=0x736e6f697463413c, ix=0)
>     at ././glib/gslice.c:855
> #1  0x00007f4e6dd5fb4e in g_slice_free1 (mem_size=<optimized out>, mem_block=0x736e6f697463413c)
>     at ././glib/gslice.c:1122
> #2  0x00007f4e6dd3daad in g_list_foreach (list=<optimized out>, 
>     list at entry=0x2ebd4a8, func=0x7f4e6f98c210, user_data=user_data at entry=0x0) at ././glib/glist.c:1005
> #3  0x00007f4e6dd3dacb in g_list_free_full (list=0x2ebd4a8, free_func=<optimized out>)
>     at ././glib/glist.c:220
> 
> > debug packages, as in https://wiki.debian.org/AutomaticDebugPackages.
> 
> Thanks, activated and installed.
> 
> Do you have any idea how to debug such a beast?

You could try setting the environment variable G_SLICE=debug-blocks so
glib will abort if it detects invalid memory releases.  That will
hopefully tell you where the invalid release happens, instead of
possibly crashing much later after memory has been corrupted.

Alternatively, valgrind can help find invalid memory reads and writes.
You'll want to set environment variable G_SLICE=always-malloc while
using valgrind with glib, and you can ignore the leak checking stuff
since you aren't looking for memory leaks.

I don't know how much help I can be though, because nemo isn't crashing
on my machine.