| From: Thomas Dickey <[EMAIL PROTECTED]> | On Sun, Feb 02, 2003 at 03:42:35AM -0500, D. Hugh Redelmeier wrote:
| > Demo of bug: | > | > - in an xterm running a shell, type: echo -e '\033[?1001h' | > - click in the window | > | > xterm now locks up (this is documented in ctlseqs.ms) and eats all | > available CPU (not documented). | hmm - running on Slackware 7.1, I don't see any CPU load. Interesting. I would not expect this to depend on which OS you used (unless it was VMS -- there are #ifdefs for vms in the relevant xterm code). But I didn't track down all possible OS dependencies. One possible system dependency: the echo command may not generate an escape on your all systems. When you run the command, the console should show a blank like and a prompt for the next shell command. If you see anything on that blank line, the echo didn't generate the sequence I intended. When you do the mouse click, you will get a few random characters echoed. I just tried KNOPPIX. It hangs burning CPU. It uses XFree86 4.2.1.1 (Debian 4.2.1-4). It hangs on all the Red Hats that I've tried here (7.0, 7.2, 7.3, 8.0, phoebe). I tried to install OpenBSD 3.0 to test it but wasted half a day on installation issues I haven't solved :-) | I'm using | a test-screen in vttest to exercise this feature. Do you mean the feature of hanging, or the feature used properly? | But I do have a | Redhat 8.0 for testing - will see if I can reproduce this problem there. I suspect that any Red Hat would do. | > Now: what about avoiding the hang altogether? I've not understood the | > code well enough to know what I'd do. | > | > The hang is fundamental. The xterm does not know how to act until | > it gets the CSI...T sequence from the pty. Perhaps a better approach | > would be to act as if a default one had been received until the actual | > one arrives. | | well yes - the xterm doesn't pay attention to anything else when it's in | that mode. That's why it's not much used. The feature is used by the JOVE text editor. That is how I stumbled across this problem. What do you think about the approach I suggested (act as if a default CSI...T sequence had been received until the real one is)? Perhaps the default should only be used after some timeout. I suspect that the CPU-burning loop happens between the sending of the mouse message and the receipt of the CSI...T even when all is well. If so, I'd say this is a bug too. Thanks, Hugh Redelmeier [EMAIL PROTECTED] voice: +1 416 482-8253 _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
