Ran gnome-terminal under xtrace (which is a tool I'm completely unfamiliar with), reproduced the crash.  Here are the last few lines of output:

000:<:0e2a:  8: RENDER-Request(149,7): FreePicture picture=0x016001e9
000:<:0e2b: 12: XInputExtension-Request(141,40): XIQueryPointer window=0x01600006 device=2
000:>:0e2b:60: Reply to XIQueryPointer: root=0x000000bb child=0x00000000 root_x=1444.000000 root_y=89.000000 win_x=162.000000 win_y=33.000000 same_screen=true(0x01) mods={base_mods=0x00000000 latched_mods=0x00000000 locked_mods=0x00000000 effective_mods=0x00000000}; groups={base_group=0x00 latched_group=0x00 locked_group=0x00 effective_group=0x00}; buttons=0x00;
000:<:0e2c: 16: Request(40): TranslateCoordinates src-window=0x01600006 dst-window=0x000000bb src-x=162 src-y=33
000:>:0e2c: Event DestroyNotify(17) event=0x03600001 window=0x03600001
000:>:0e2c:32: Reply to TranslateCoordinates: same-screen=true(0x01) child=0x01a26e12 dst-x=1444 dst-y=89
000:<:0e2d: 24: Request(18): ChangeProperty mode=Replace(0x00) window=0x03600001 property=0x25c("XSEL_DATA") type=0x13b("UTF8_STRING") data=;
000:>:0e2d:Error 3=Window: major=18, minor=0, bad=56623105

(gnome-terminal:5601): Gdk-WARNING **: The program 'gnome-terminal' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 3629 error_code 3 request_code 18 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

I have a full xtrace log (8 megs) if you think it is useful.

It seems to me xsel is also doing bad things here (destroying windows prematurely, not receiving any selection data -- the /tmp/PLEASEDONTCRASH file is empty after a crash), but that doesn't mean gnome-terminal should be allowed to crash and take down all my open tabs.

I wasn't able to reproduce the crash by using xclip -o instead of xsel, so at least there's a workaround of sorts.

Not reproducible here using gtk+ master, vte-0-32 and gnome-terminal gnome-3-4.

Reproduced this on Gnome 3.2 (openSUSE 12.1).

Whats /tmp/PLEASEDONTCRASH btw? :)

If you run xsel with a lot of verbosity, it shows this:

cacharro$ xsel -vvvvvvvvvvvv
xsel: Window id: 0x3400001 (unmapped)
xsel: Timestamp: 3387704609
xsel: Maximum request size: 4000 bytes
xsel: Got window property: requestor 0x3400001, property 0x2c2, target 0x1f6 INCR, length 1 bytes
xsel: Initialising incremental retrieval of at least 709856 bytes

xsel: Deleting property that informed of INCR transfer
xsel: Waiting on PropertyNotify events
xsel: Got window property: requestor 0x3400001, property 0x2c2, target 0x149 UTF8_STRING, length 262144 bytes
xsel: target UTF8_STRING not XA_STRING in get_append_property()
xsel: Finished INCR retrieval
xsel: Got window property: requestor 0x3400001, property 0x2c2, target 0x1f6 INCR, length 1 bytes
xsel: Initialising incremental retrieval of at least 709856 bytes

xsel: Deleting property that informed of INCR transfer
xsel: Waiting on PropertyNotify events
xsel: Got window property: requestor 0x3400001, property 0x2c2, target 0x149 UTF8_STRING, length 185568 bytes
xsel: target UTF8_STRING not XA_STRING in get_append_property()
xsel: Finished INCR retrieval

Note the second-last line, "target UTF8_STRING not XA_STRING...".  The source from xsel.c says:

static Boolean
get_append_property (XSelectionEvent * xsl, unsigned char ** buffer,
                     int * offset, int * alloc)
{
  ...

  XGetWindowProperty (xsl->display, xsl->requestor, xsl->property,
                      0L, 1000000, True, (Atom)AnyPropertyType,
                      &target, &format, &length, &bytesafter, &value);

  debug_property (D_TRACE, xsl->requestor, xsl->property, target, length);

  if (target != XA_STRING) {
    print_debug (D_OBSC, "target %s not XA_STRING in get_append_property()",
                 get_atom_name (target));
    free (*buffer);
    *buffer = NULL;
    return False;
  } ...

At that point, the caller is wait_incr_selection().  When it gets the False back from get_append_property(), it returns NULL ("empty selection") and the program terminates.  That of course destroys its window, and GTK+ chokes.

So, there's two possible issues here:

1. Should xsel accept UTF8_STRING instead of plain XA_STRING in INCR selections?  Sounds like it should, but I don't know how INCR selections work.

2. Should GTK+ protect itself against selection windows disappearing?  Most likely, yes.

Reassigning to GTK+.

Created attachment 208710 [details] [review]
xsel-utf8-incr.diff

... and with this little patch, xsel works.

Already sent the xsel patch upstream.

We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.