This is going to be a tough one to track down if we can't reproduce it.

The relevant piece of GLib code says:

471 	  	  	guint
472 	  	  	g_list_length (GList *list)
473 	  	  	{
474 	  	  	  guint length;
475 	  	  	
476 	  	  	  length = 0;
477 	  	  	  while (list)
478 	  	  	  {
479 	  	  	    length++;
480 	  	  	    list = list->next;
481 	  	  	  }
482 	  	  	
483 	  	  	  return length;
484 	  	  	}

According to the stack trace, length==0, but you can see from the above that the only things that can happen while length==0 are the local variable "list" being checked for being null, and the function returning zero. In particular it is impossible to dereference "list" while length==0 (though perhaps there's some funky caching thing going on).

Can you reproduce this bug? What were you actually doing, not moving windows around or switching between windows or anything? Were you just typing away, or were you not touching the computer at all?

Oops, made a comment on Launchpad last night that should have been here too:

FWIW, the call to g_list_length here is pretty useless except if you have logging on. We should probably remove it unless you do, and save a few cycles. On the other hand, it wouldn't fix this crash, since it's not *really* a problem with g_list_length but with the rectangle list containing a pointer outside the segment. We can't tell what that rectangle list was, since that depends on what called do_screen_and_xinerama_relative_constraints(), and that information's been optimised away. Unless we can find out more, we're going to have to close this for lack of information.

I did actually add a check for verbose mode yesterday, so that the log message's size and content are not calculated unless it'll be used, and hence g_list_length won't be called.  This closes the presenting problem.  But we still have the difficulty that the presenting problem can only have been caused by a degenerate list, which would have caused problems further down the line, and the real problem would have been finding where this list went bad.  However, we can't do that unless we can replicate, and we've only had one report of this problem.  Hence, I'm closing this as INVALID.  However, if this happens again, let us know.