Repeatable bug since src/process.c v1.403

Repeatable bug since src/process.c v1.403

[Fabrice Bauzac]

Hello,

In GNU Emacs 21.3.2 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2003-04-24 on raven, modified by Debian
configured using `configure  i386-linux --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --with-x=yes --with-x-toolkit=athena --without-gif'
Important settings:
  value of $LC_ALL: fr_FR
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: fr_FR
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Starting from Emacs CVS of 2003-03-09, I have this behavior:

* Start Emacs;
* Start a Eshell buffer;
* Start mutt (Eshell starts term-mode for that);
* Do many things from inside Mutt.

At some point, Emacs crashes.  This is what I get with 2003-05-17 CVS:

================================================================
bash-2.05b$ gdb ./emacs
GNU gdb 5.3-debian
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...(no debugging symbols found)...
DISPLAY = :0.0
TERM = dumb
Breakpoint 1 at 0x8132c27
Breakpoint 2 at 0x810d51b
(gdb) r
Starting program: /home/noon/prog/cvs/build-emacs-20030517-bug/src/emacs -geometry 80x40+0+0
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x08190a38 in compact_small_strings ()
(gdb) bt
#0  0x08190a38 in compact_small_strings ()
#1  0x08190974 in sweep_strings ()
#2  0x0819480a in gc_sweep ()
#3  0x08193414 in Fgarbage_collect ()
#4  0x081ad816 in Ffuncall ()
#5  0x081e58f8 in Fbyte_code ()
#6  0x081ae20c in funcall_lambda ()
#7  0x081adc55 in Ffuncall ()
#8  0x081ad2e2 in Fapply ()
#9  0x081ad6a8 in apply1 ()
#10 0x081ee3da in read_process_output_call ()
#11 0x081ab9f1 in internal_condition_case_1 ()
#12 0x081ee8b5 in read_process_output ()
#13 0x081ee01a in wait_reading_process_input ()
#14 0x0808a43c in sit_for ()
#15 0x08138e2c in read_char ()
#16 0x0814225e in read_key_sequence ()
#17 0x0813613f in command_loop_1 ()
#18 0x081ab8c8 in internal_condition_case ()
#19 0x08135c72 in command_loop_2 ()
#20 0x081ab379 in internal_catch ()
#21 0x08135c25 in command_loop ()
#22 0x081356f2 in recursive_edit_1 ()
#23 0x08135821 in Frecursive_edit ()
#24 0x08134219 in main ()
#25 0x4059aa51 in __libc_start_main () from /lib/libc.so.6
(gdb)
================================================================

Since I don't know well how Emacs works, I managed to find (by
dichotomy) at which date the CVS version began to crash this way with
this reproductible bug.

The bug seems to have appeared on 2003-03-09 with a modification on
src/process.c:

================================================================
bash-2.05b$ cvs -qz3 diff -u -r1.402 -r1.403 process.c
Index: process.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/process.c,v
retrieving revision 1.402
retrieving revision 1.403
diff -u -r1.402 -r1.403
--- process.c	21 Feb 2003 18:13:53 -0000	1.402
+++ process.c	9 Mar 2003 22:48:08 -0000	1.403
@@ -4463,18 +4463,18 @@
   if (DATAGRAM_CHAN_P (channel))
     {
       int len = datagram_address[channel].len;
-      nbytes = recvfrom (channel, chars + carryover, readmax - carryover,
+      nbytes = recvfrom (channel, chars + carryover, readmax,
 			 0, datagram_address[channel].sa, &len);
     }
   else
 #endif
   if (proc_buffered_char[channel] < 0)
-    nbytes = emacs_read (channel, chars + carryover, readmax - carryover);
+    nbytes = emacs_read (channel, chars + carryover, readmax);
   else
     {
       chars[carryover] = proc_buffered_char[channel];
       proc_buffered_char[channel] = -1;
-      nbytes = emacs_read (channel, chars + carryover + 1,  readmax - 1 - carryover);
+      nbytes = emacs_read (channel, chars + carryover + 1,  readmax - 1);
       if (nbytes < 0)
 	nbytes = 1;
       else
================================================================

I reverted this diff on my local copy of the latest Emacs CVS, and
then tried to crash Emacs with the same test.  It hasn't crashed yet,
I am pretty sure the bug is not there anymore.  I'm sure because when
my test crashed Emacs, it always did so at a certain point (about 250
scrollups of mutt's cursor); and that point is largely past and Emacs
hasn't crashed.

I don't know at all what the carryover variable means, all I can do is
patch and try.  But if you need any help from me, please tell me what
to do, patch or test.  I'd be glad to help.

Have a nice day,

-- 
fabrice bauzac
Software should be free.  http://www.gnu.org/philosophy/why-free.html

Re: Repeatable bug since src/process.c v1.403

[David Kastrup]

Fabrice Bauzac <noon@noon.dnsalias.net> writes:

> In GNU Emacs 21.3.2 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>  of 2003-04-24 on raven, modified by Debian
> configured using `configure  i386-linux --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --with-x=yes --with-x-toolkit=athena --without-gif'

> The bug seems to have appeared on 2003-03-09 with a modification on
> src/process.c:

> I don't know at all what the carryover variable means, all I can do is
> patch and try.  But if you need any help from me, please tell me what
> to do, patch or test.  I'd be glad to help.

My fault.  I changed the code because there was enough memory
allocated for accommodating the I/O.  I backed the change out again,
even though I have no idea why it would cause a problem.  Could you
alternatively try removing the "+ carryover" from the argument to
alloca a few lines above, and see whether this would again cause the
crashes you experienced?

I hate it if one has to allocate more memory than properly needed,
this points to a thinko or possibly other problem elsewhere.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Repeatable bug since src/process.c v1.403

[Fabrice Bauzac]

Hello,

Note: I'm not on the bug-gnu-emacs mailing-list at the moment: please
CC.

I changed the alloca line in process.c, and the test doesn't crash
Emacs:

Excerpt of process.c
================================================================
#ifdef DATAGRAM_SOCKETS
  /* A datagram is one packet; allow at least 1500+ bytes of data
     corresponding to the typical Ethernet frame size.  */
  if (DATAGRAM_CHAN_P (channel))
    {
      /* carryover = 0; */  /* Does carryover make sense for datagrams? */
      readmax += 1024;
    }
#endif

/*   chars = (char *) alloca (carryover + readmax); */
  chars = (char *) alloca (readmax);
  if (carryover)
    /* See the comment above.  */
    bcopy (SDATA (p->decoding_buf), chars, carryover);

#ifdef DATAGRAM_SOCKETS
  /* We have a working select, so proc_buffered_char is always -1.  */
  if (DATAGRAM_CHAN_P (channel))
    {
      int len = datagram_address[channel].len;
      nbytes = recvfrom (channel, chars + carryover, readmax - carryover,
			 0, datagram_address[channel].sa, &len);
    }
  else
#endif
  if (proc_buffered_char[channel] < 0)
    nbytes = emacs_read (channel, chars + carryover, readmax - carryover);
  else
    {
      chars[carryover] = proc_buffered_char[channel];
      proc_buffered_char[channel] = -1;
      nbytes = emacs_read (channel, chars + carryover + 1,  readmax - 1 - carryover);
      if (nbytes < 0)
	nbytes = 1;
      else
	nbytes = nbytes + 1;
    }
#endif /* not VMS */
================================================================

I then un-reverted the 1.403 patch and it crashed:

Excerpt of process.c
================================================================
#ifdef DATAGRAM_SOCKETS
  /* A datagram is one packet; allow at least 1500+ bytes of data
     corresponding to the typical Ethernet frame size.  */
  if (DATAGRAM_CHAN_P (channel))
    {
      /* carryover = 0; */  /* Does carryover make sense for datagrams? */
      readmax += 1024;
    }
#endif

/*   chars = (char *) alloca (carryover + readmax); */
  chars = (char *) alloca (readmax);
  if (carryover)
    /* See the comment above.  */
    bcopy (SDATA (p->decoding_buf), chars, carryover);

#ifdef DATAGRAM_SOCKETS
  /* We have a working select, so proc_buffered_char is always -1.  */
  if (DATAGRAM_CHAN_P (channel))
    {
      int len = datagram_address[channel].len;
      nbytes = recvfrom (channel, chars + carryover, readmax,
			 0, datagram_address[channel].sa, &len);
    }
  else
#endif
  if (proc_buffered_char[channel] < 0)
    nbytes = emacs_read (channel, chars + carryover, readmax);
  else
    {
      chars[carryover] = proc_buffered_char[channel];
      proc_buffered_char[channel] = -1;
      nbytes = emacs_read (channel, chars + carryover + 1,  readmax - 1);
      if (nbytes < 0)
	nbytes = 1;
      else
	nbytes = nbytes + 1;
    }
#endif /* not VMS */
================================================================

Hope this helps.  Tell me if I can do anything else.

-- 
fabrice bauzac
Software should be free.  http://www.gnu.org/philosophy/why-free.html