Due to what I believe is a bug in Gnome shell or a Gnome shell extension
that I have running, I am experiencing places where Emacs will lock up
completely.  

Under some unknown circumstances, when idle for a long while, sometimes
gnome shell on my system will enter the activities overview instead of
blanking the screen.  Why it does this is unknown, is likely a bug in
gnome shell or one of my gnome extensions, and is likely itself
unrelated to Emacs.  When I exit this state, though, Emacs is in a
locked-up, unpainted (blank) state and will not respond to anything
short of a SIGTERM.  Sending a SIGTERM will cause a frame to redraw, but
Emacs remains in a locked and useless state.  With a second SIGTERM,
emacs exits.

I have attached to the locked up Emacs in a gdb session.  I've done this
twice, and each time the backtrace was nearly identical, locking up in
deep within XSetICValues() in xic_set_preeditarea().  This has been
ocurring about once every two days, on average, so I can probably
recreate it, if desired.

I do not think this is necessarily a bug in Emacs, per se, but I am
hoping that someone can look at the backtrace and have some idea what is
going on.  Maybe there is a workaround that can be used.  This is not
the only program I regularly run that locks up this way.  A multitail
process I have running in an xterm ends up behaving in a similar
fashion.

Backtrace follows: