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@entry=0x2ebd4a8, func=0x7f4e6f98c210, user_data=user_data@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.
