emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Invalid output to process


From: Milan Zamazal
Subject: Invalid output to process
Date: Wed, 02 Nov 2005 19:50:04 +0100

Under some circumstances the call (process-send-string PROCESS STRING)
sends a string somewhat different from STRING to PROCESS.  This bug
appears in both recent Emacs CVS snapshot and Emacs 21.4.

The bug is reproducible, but it requires some work.  I'm sorry but I was
unable to find an easier way to reproduce it (see explanation at the end
-- perhaps you can give me some advice).  How to reproduce the bug:

- Install BrlTTY 3.7, available from
  http://www.mielke.cc/brltty/releases/brltty-3.7.tar.gz or perhaps your
  favorite OS distribution.

- Run BrlTTY under X as:

  ./brltty -e -n -b xw -x as -l 7

- Run Emacs and load the following two files:

Attachment: speechd-common.el
Description: application/emacs-lisp

Attachment: brltty.el
Description: application/emacs-lisp

- Open the following Elisp file and perform `M-x eval-current-buffer':

Attachment: bug1.el
Description: application/emacs-lisp

  String "hello" should appear on the BrlTTY display.  The following
  string "\236" is crippled when sent to BrlTTY.  process-send-string
  call receives "\236                                       " (character
  \236 and 39 spaces) as its argument.  But Emacs actually sends
  (as reported by a network sniffer)
  "\0                                      " (character \0 and 38
  spaces) instead, i.e. the first character gets changed and one space
  is omitted.  This is a bug.

- Now you can examine the bug in a simpler way, proving there is an
  Emacs bug outside the attached Elisp files.  Run any TCP server which
  can receive and print input received from a socket.  (I use `socket'
  available from
  http://http.us.debian.org/debian/pool/main/s/socket/socket_1.1.orig.tar.gz
  and run it as `socket -s 1234'.)

- Open the following Elisp file and perform `M-x eval-current-buffer'
  (assuming the server is running on port 1234):

Attachment: bug2.el
Description: application/emacs-lisp

  When you examine the content of `foo' variable, you can see it differs
  from the input received by the server, particularly the \236 character
  is missing.  This is the bug.

Why I can't just send you the content of `foo' variable?  Because when I
put its value into a buffer and then read it from the buffer, the read
value is equalp to the original `foo' value, but the bug can't be
reproduced with the new value.  I don't understand how this can happen.
If I apply copy-sequence or substring-no-properties on the original
`foo' values, I can still reproduce the bug.  But if I apply
string-to-list to the elements and then convert them back to strings,
the bug is no longer reproducible despite all the lists are still
equalp.  Yes, I tried to debug the send_process C function but that
failed on a gdb error:

nevyn/local/gdb/gdb-6.3/gdb/infrun.c:2642: internal-error: 
insert_step_resume_breakpoint_at_sal: Assertion `step_resume_breakpoint == 
NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.


In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, X toolkit)
 of 2005-11-01 on blackbird
X server distributor `The XFree86 Project, Inc', version 11.0.40300001
configured using `configure '--prefix=/usr/local/stow/emacs-cvs' 
'--with-toolkit=lucid''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: cs_CZ.UTF-8
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

reply via email to

[Prev in Thread] Current Thread [Next in Thread]