xterm freeze when accepting input from usb scanner

This sounds like a problem with the application rather than xterm.
For instance, there are a few applications which have hardcoded
escape sequences for Linux console's nonstandard color palettes.
XTerm has a workaround for that (the brokenLinuxOSC resource setting).

Some other applications do... interesting things because they do not
know about 8-bit controls. Again, xterm has a workaround for those
(the allowC1Printable resource setting).

Finally, there are others which (again relying upon some misfeatures
in Linux console) can be worked around using brokenStringTerm.

These are all in the manpage - http://invisible-island.net/xterm/manpage/xterm.html

Thomas: This issue is reproducible simply by attempting to scan a barcode into the xterm window NOT a child process, I was simply indicating that it happened in both places. The USB scanner is acting as a basic character-input device when used like this. There's no special application running it's just detected by Ubuntu as a Symbol Scanner and then I'm opening an xterm window and trying to scan something, at this point xterm completely locks up, can't cntrl-c can't click X to kill it. Have to manually open another terminal and kill the xterm process. However, the Scanner will work properly using any other application that was not launched using xterm. For instance I can launch lxterminal and it accepts the scan as text input just fine, same with a web browser, or leafpad.

Also, this is not an issue on our previous system installation which uses Ubuntu Maverick & has xterm 261-1ubuntu3 installed, it's only happening on Trusty with xterm 297-1ubuntu1.

Without knowing what characters are sent/received, I cannot offer advice other than
to point to known problems with applications in this area.

Thomas,
  The characters being sent/received are normal ASCII characters, we're doing Vin code scanning so it's even in the domain A-Z 0-9 like I said, it was working fine on an older version of xterm.

If that were so, then there would be a lot of bug reports
(control-characters would be something to check, but plain ASCII does not sound plausible).

Thanks, I'll try running with -k8 and other settings to see if I can't get it to respond differently!

Here's what xterm is apparently seeing when I scan a barcode and use the -l option to log the output.

^[]0;isisup@LUBE151: ~^Gisisup@LUBE151:~$ 1G

The 1G is the first 2 printed characters of the barcode in this case, but there are 15 more it should have kept reading instead locking up.

Using another barcode I get this:
^[]0;isisup@LUBE151: ~^Gisisup@LUBE151:~$ 3B5

The 3B5 is actually incorrect in this case, the barcode I scanned is should be showing 3B7 then another 14 characters.

Now I tried the same thing on the older version of xterm and it also has the same control characters in the log to start with, but will finish scanning the full barcode to the command line. Any ideas on this?

I worked with Zebra on this and was able to get the scanner working by reducing the USB polling interval on the scanner to 8msec, the default is to poll every 3msec. I still believe this is a bug in how xterm accepts input because of the following:

A) This issue does not occur when accepting input as root.
B) This issue does not occur on older versions of xterm (261 was tested)
C) This issue does not occur when accepting input into other applications or windows.

Reading the manual, I see that the DS4208 is talking via RS-232, which would make xterm's
role in this mostly as a bystander, since (unless you've made your keyboard the serial device,
it would only be echoing something).

The -l option doesn't show me much either, except for your shell prompt (which looks a
little odd with the doubled ^G and the tilde). Perhaps if you had added that as an attachment,
I could see better what it's recording. However, what that records is a little downstream of
the actual input -- it's possible that something is lost in the story. As I noted, the usual problem
is due to some incomplete control sequence, for which there are documented workarounds.

"accepting input as root" raises the possibility that your shell prompt isn't the same, and
that there's something amiss there. A "typescript" from "script" (as an attachment) would
show what is sent to the terminal, and is helpful in spotting broken control sequences.

Capturing all of the input sent from the scanner is harder, since that's received in xterm
as a series of X events - which are processed into characters.

There are perhaps better ways to trace this, but generally I build xterm with a debugging
trace, which would show all of the input events.

Thanks for the response Thomas. The DS4208 has multiple cables that it can be plugged in with, the xterm issues are when it is plugged in over USB. RS232 is not used for doing direct-text input.