Yes, the crashes have been from corruption of the statefile and slick-c heap, so it's entirely possible for a bad state file to have been written for one of these.
I've been looking at xretrace, and I'm no longer so certain it's not playing a role in the crashes. It's using pointers for/around the list functions, and Slick-C's garbage collector is not a tracing garbage collector. So if you have a pointer that points to a value in an array or hashtable, and you modify the array/hashtable so it needs to dynamically resize, that pointer is left pointing into the Slick-C heap at a location that's going to be storage for something else. And writing to that location can do a lot of damage, due to the way the values are represented in memory.
The most worrying is in dist_insert() in DLinkList.e. On line 546, it takes a pointer to an array value in the list's `nodes` member. On the face of it, it looks ok, because there's a previous call to dlist_get_new_node() before the pointer is taken. But when there are no nodes on the free list, that function just returns the index of the next node to use, so the possible re-allocation of the nodes array doesn't happen till the array assignment later on at 558. And then a modification through the pointer on line 559.
There's also a case in xretrace_add_bookmark_for_buffer() where it modifies the buffer_bookmark_list:[] hashtable, while it might be possible there's a global pointer ptr_bookmark_list_for_buffer pointing to one of the values in the hashtable. I don't consider this one as likely, as I can't see it in practice when that pointer is non-null, and it looks like it can only trigger when the xretrace scrollbar is up.
This isn't an exhaustive list, I haven't looked through all of the code yet. I had looked at dlist_insert() about 3 times before I spotted the problem there. I need to take a break to get some hotfixes off my backlog, and then I'll go through the rest with fresh eyes, and see if I can find anything else.