Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!enea!zyx!aj
From: aj@zyx.UUCP (Arndt Jonasson)
Newsgroups: comp.emacs
Subject: Problems with GNU Emacs 17.62 on Apollo 9.2.5.
Message-ID: <442@zyx.UUCP>
Date: Mon, 27-Apr-87 14:15:41 EDT
Article-I.D.: zyx.442
Posted: Mon Apr 27 14:15:41 1987
Date-Received: Sat, 2-May-87 02:19:08 EDT
Reply-To: aj@zyx.UUCP (Arndt Jonasson, ZYX Sweden AB, Stockholm)
Organization: ZYX Sweden AB, Stockholm
Lines: 79

This will only interest users of GNU Emacs on Apollo.

Apart from the well-known problem of the Apollo OS's not supporting dumping
Emacs, I have found a number of bugs in various places.

1) read-from-string

When the local variables in a file are processed by Emacs, at a certain point,
a 'read' operation is performed on a string. This read operation hangs, because
of a bug in the C compiler. The relevant lines in lread.c are:

    return (read_from_string_index < read_from_string_limit) ?
      (XSTRING (readcharfun)->data[read_from_string_index++]) : -1;

where the data array has type 'unsigned char'. When the end of the string has
been reached, the -1 is returned, but because of incorrect type conversions,
255 is the actual value returned. The 'fix' in this case was to cast the
character value to (int), thus:

      (int) (XSTRING (readcharfun)->data[read_from_string_index++]) : -1;

2) waiting for subprocess

When Emacs spawns a synchronous subprocess, it starts the process, does some
administrative tasks, and then enters the function 'wait_for_termination' to
wait for that particular subprocess to exit. In this funciton, when Emacs is
woken up by a SIGCLD signal, it checks with a call to 'kill' whether the
interesting subprocess was the one which exited. If it wasn't, Emacs returns
to sleep.

The bug is that, although the process exited, 'kill (pid, 0)' still reports
that the process exists. This appears to be a bug in the implementation of
the BSD4.2 Apollo/IX kernel.

A similar problem exists (according to a source code comment) when an 'execv'
fails in BSD4.2. The solution is the same: use an 'alarm' to forcibly wake
up Emacs again after one second. At the second or third 'kill (pid, 0)', 'kill'
will correctly report that the process doesn't exist. In the file sysdep.c,
replace the lines

      if (wait_debugging)
	sleep (1);
      else
	sigpause (0);

with

      if (wait_debugging)
	sleep (1);
      else
	{
	  int create_process_1 ();

	  signal (SIGALRM, create_process_1);
	  alarm (1);
	  sigpause (0);
	  alarm (0);
	}

3) file-changed-date incorrect

There is another presumably kernel bug, which causes Emacs to frequently report
that a file has changed on disk when it hasn't. In fileio.c, 'fstat' is done on
a file descriptor, whereafter the file is closed. The act of closing the file
changes the file modified date, which makes Emacs's idea of when the file was
saved incorrect. Thus, when the file is saved the next time. Emacs will detect
that the saved and the actual modified dates aren't the same, and therefore it
outputs a message saying that the file has changed.

This may be due to incorrect assumptions in Emacs about the behaviour of file
descriptors and doing 'fstat' on them. A Unix wizard might answer that.

The fix I did was to do a 'stat' after the 'close', instead of an 'fstat'
before the 'close'. Now it works, most of the time. However, now and then, the
same error appears again. This cannot possibly be Emacs's fault, but is
probably a bug in the kernel.
-- 
Arndt Jonasson, ZYX Sweden AB, Styrmansgatan 6, 114 54 Stockholm, Sweden
UUCP: ...!seismo!mcvax!enea!zyx!aj