![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to PROBLEMS CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / emacs-18.55|
Return to PROBLEMS CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / emacs-18.55 |
1.1 root 1: This file describes various problems that have been encountered
2: in compiling, installing and running GNU Emacs.
3:
4: * Error compiling sysdep.c, "sioctl.h: no such file or directory".
5:
6: Among USG systems with TIOCGWINSZ, some require sysdep.c to include
7: the file sioctl.h; on others, sioctl.h does not exist. We don't know
8: how to distinguish these two kind of systems, so currently we try to
9: include sioctl.h on all of them. If this #include gets an error, just
10: delete it.
11:
12: * X Windows doesn't work if DISPLAY uses a hostname.
13:
14: People have reported kernel bugs in certain systems that cause Emacs
15: not to work with X Windows if DISPLAY is set using a host name. But
16: the problem does not occur if DISPLAY is set to `unix:0.0'. I think
17: the bug has to do with SIGIO or FIONREAD.
18:
19: You may be able to compensate for the bug by doing (set-input-mode nil nil).
20: However, that has the disadvantage of turning off interrupts, so that
21: you are unable to quit out of a Lisp program by typing C-g.
22:
23: The easy way to do this is to put
24:
25: (setq x-sigio-bug t)
26:
27: in your site-init.el file.
28:
29: * Watch out for .emacs files and EMACSLOADPATH environment vars
30:
31: These control the actions of Emacs.
32: ~/.emacs is your Emacs init file.
33: EMACSLOADPATH overrides which directories the function
34: "load" will search.
35:
36: If you observe strange problems, check for these and get rid
37: of them, then try again.
38:
39: * Fatal signal in the command temacs -l loadup inc dump
40:
41: This command is the final stage of building Emacs. It is run by the
42: Makefile in the src subdirectory, or by build.com on VMS.
43:
44: It has been known to get fatal errors due to insufficient swapping
45: space available on the machine.
46:
47: On 68000's, it has also happened because of bugs in the
48: subroutine `alloca'. Verify that `alloca' works right, even
49: for large blocks (many pages).
50:
51: * test-distrib says that the distribution has been clobbered
52: * or, temacs prints "Command key out of range 0-127"
53: * or, temacs runs and dumps xemacs, but xemacs totally fails to work.
54: * or, temacs gets errors dumping xemacs
55:
56: This can be because the .elc files have been garbled. Do not be
57: fooled by the fact that most of a .elc file is text: these are
58: binary files and can contain all 256 byte values.
59:
60: In particular `shar' cannot be used for transmitting GNU Emacs.
61: It typically truncates "lines". What appear to be "lines" in
62: a binary file can of course be of any length. Even once `shar'
63: itself is made to work correctly, `sh' discards null characters
64: when unpacking the shell archive.
65:
66: I have also seen character \177 changed into \377. I do not know
67: what transfer means caused this problem. Various network
68: file transfer programs are suspected of clobbering the high bit.
69:
70: The only verified ways to transfer GNU Emacs are `tar', kermit (in
71: binary mode on Unix), and rcp or internet ftp between two Unix systems,
72: or chaosnet cftp using raw mode.
73:
74: If you have a copy of Emacs that has been damaged in its
75: nonprinting characters, you can fix them:
76:
77: 1) Record the names of all the .elc files.
78: 2) Delete all the .elc files.
79: 3) Recompile alloc.c with a value of PURESIZE twice as large.
80: You might as well save the old alloc.o.
81: 4) Remake xemacs. It should work now.
82: 5) Running xemacs, do Meta-x byte-compile-file repeatedly
83: to recreate all the .elc files that used to exist.
84: You may need to increase the value of the variable
85: max-lisp-eval-depth to succeed in running the compiler interpreted
86: on certain .el files. 400 was sufficient as of last report.
87: 6) Reinstall the old alloc.o (undoing changes to alloc.c if any)
88: and remake temacs.
89: 7) Remake xemacs. It should work now, with valid .elc files.
90:
91: * temacs prints "Pure Lisp storage exhausted"
92:
93: This means that the Lisp code loaded from the .elc and .el
94: files during temacs -l loadup inc dump took up more
95: space than was allocated.
96:
97: This could be caused by
98: 1) adding code to the preloaded Lisp files
99: 2) adding more preloaded files in loadup.el
100: 3) having a site-init.el or site-load.el which loads files.
101: Note that ANY site-init.el or site-load.el is nonstandard;
102: if you have received Emacs from some other site
103: and it contains a site-init.el or site-load.el file, consider
104: deleting that file.
105: 4) getting the wrong .el or .elc files
106: (not from the directory you expected).
107: 5) deleting some .elc files that are supposed to exist.
108: This would cause the source files (.el files) to be
109: loaded instead. They take up more room, so you lose.
110: 6) a bug in the Emacs distribution which underestimates
111: the space required.
112:
113: If the need for more space is legitimate, change the definition
114: of PURESIZE in config.h.
115:
116: But in some of the cases listed above, this problem is a consequence
117: of something else that is wrong. Be sure to check and fix the real
118: problem.
119:
120: * Changes made to .el files do not take effect.
121:
122: You may have forgotten to recompile them into .elc files.
123: Then the old .elc files will be loaded, and your changes
124: will not be seen. To fix this, do M-x byte-recompile-directory
125: and specify the directory that contains the Lisp files.
126:
127: * The dumped Emacs (xemacs) crashes when run, trying to write pure data.
128:
129: Two causes have been seen for such problems.
130:
131: 1) On a system where getpagesize is not a system call, it is defined
132: as a macro. If the definition (in both unexec.c and malloc.c) is wrong,
133: it can cause problems like this. You might be able to find the correct
134: value in the man page for a.out (5).
135:
136: 2) Some systems allocate variables declared static among the
137: initialized variables. Emacs makes all initialized variables in most
138: of its files pure after dumping, but the variables declared static and
139: not initialized are not supposed to be pure. On these systems you
140: may need to add "#define static" to the m- or the s- file.
141:
142: * Compilation errors on VMS.
143:
144: You will get warnings when compiling on VMS because there are
145: variable names longer than 32 (or whatever it is) characters.
146: This is not an error. Ignore it.
147:
148: VAX C does not support #if defined(foo). Uses of this construct
149: were removed, but some may have crept back in. They must be rewritten.
150:
151: There is a bug in the C compiler which fails to sign extend characters
152: in conditional expressions. The bug is:
153: char c = -1, d = 1;
154: int i;
155:
156: i = d ? c : d;
157: The result is i == 255; the fix is to typecast the char in the
158: conditional expression as an (int). Known occurrences of such
159: constructs in Emacs have been fixed.
160:
161: * rmail gets error getting new mail
162:
163: rmail gets new mail from /usr/spool/mail/$USER using a program
164: called `movemail'. This program interlocks with /bin/mail using
165: the protocol defined by /bin/mail.
166:
167: There are two different protocols in general use. One of them uses
168: the `flock' system call. The other involves creating a lock file;
169: `movemail' must be able to write in /usr/spool/mail in order to do
170: this. You control which one is used by defining, or not defining,
171: the macro MAIL_USE_FLOCK in config.h or the m- or s- file it includes.
172: IF YOU DON'T USE THE FORM OF INTERLOCKING THAT IS NORMAL ON YOUR
173: SYSTEM, YOU CAN LOSE MAIL!
174:
175: If your system uses the lock file protocol, and fascist restrictions
176: prevent ordinary users from writing the lock files in /usr/spool/mail,
177: you may need to make `movemail' setgid to a suitable group such as
178: `mail'.
179:
180: * Emacs won't work with X-windows if the value of DISPLAY is HOSTNAME:0.
181:
182: Some people have found that Emacs was unable to connect to the local
183: host by name, as in DISPLAY=prep:0 if you are running on prep, but
184: could handle DISPLAY=unix:0. Here is what [email protected] said:
185:
186: Seems as
187: though gethostbyname was bombing somewhere along the way. Well, we
188: had just upgrade from SunOS 3.5 (which X11 was built under) to SunOS
189: 4.0.1. Any new X applications which tried to be built with the pre
190: OS-upgrade libraries had the same problems which Emacs was having.
191: Missing /etc/resolv.conf for a little while (when one of the libraries
192: was built?) also might have had a hand in it.
193:
194: The result of all of this (with some speculation) was that we rebuilt
195: X and then rebuilt Emacs with the new libraries. Works as it should
196: now. Hoorah.
197:
198: * Emacs spontaneously displays "I-search: " at the bottom of the screen.
199:
200: This means that Control-S/Control-Q "flow control" is being used.
201: C-s/C-q flow control is bad for Emacs editors because it takes away
202: C-s and C-q as user commands. Since editors do not output long streams
203: of text without user commands, there is no need for a user-issuable
204: "stop output" command in an editor; therefore, a properly designed
205: flow control mechanism would transmit all possible input characters
206: without interference. Designing such a mechanism is easy, for a person
207: with at least half a brain.
208:
209: There are three possible reasons why flow control could be taking place:
210:
211: 1) Terminal has not been told to disable flow control
212: 2) Insufficient padding for the terminal in use
213: 3) Some sort of terminal concentrator or line switch is responsible
214:
215: First of all, many terminals have a set-up mode which controls
216: whether they generate flow control characters. This must be
217: set to "no flow control" in order for Emacs to work. Sometimes
218: there is an escape sequence that the computer can send to turn
219: flow control off and on. If so, perhaps the termcap `ti' string
220: should turn flow control off, and the `te' string should turn it on.
221:
222: Once the terminal has been told "no flow control", you may find it
223: needs more padding. The amount of padding Emacs sends is controlled
224: by the termcap entry for the terminal in use, and by the output baud
225: rate as known by the kernel. The shell command `stty' will print
226: your output baud rate; `stty' with suitable arguments will set it if
227: it is wrong. Setting to a higher speed causes increased padding. If
228: the results are wrong for the correct speed, there is probably a
229: problem in the termcap entry. You must speak to a local Unix wizard
230: to fix this. Perhaps you are just using the wrong terminal type.
231:
232: For terminals that lack a "no flow control" mode, sometimes just
233: giving lots of padding will prevent actual generation of flow control
234: codes. You might as well try it.
235:
236: If you are really unlucky, your terminal is connected to the computer
237: through a concentrator which sends flow control to the computer, or it
238: insists on sending flow control itself no matter how much padding you
239: give it. You are screwed! You should replace the terminal or
240: concentrator with a properly designed one. In the mean time,
241: some drastic measures can make Emacs semi-work.
242:
243: One drastic measure to ignore C-s and C-q, while sending enough
244: padding that the terminal will not really lose any output.
245: Ignoring C-s and C-q can be done by using keyboard-translate-table
246: to map them into an undefined character such as C-^ or C-\. Sending
247: lots of padding is done by changing the termcap entry. Here is how
248: to make such a keyboard-translate-table:
249:
250: (let ((the-table (make-string 128 0)))
251: ;; Default is to translate each character into itself.
252: (let ((i 0))
253: (while (< i 128)
254: (aset the-table i i)
255: (setq i (1+ i))))
256: ;; Swap C-s with C-\
257: (aset the-table ?\C-\\ ?\C-s)
258: (aset the-table ?\C-s ?\C-\\)
259: ;; Swap C-q with C-^
260: (aset the-table ?\C-^ ?\C-q)
261: (aset the-table ?\C-q ?\C-^)
262: (setq keyboard-translate-table the-table))
263:
264: An even more drastic measure is to make Emacs use flow control.
265: To do this, evaluate the Lisp expression (set-input-mode nil t).
266: Emacs will then interpret C-s and C-q as flow control commands. (More
267: precisely, it will allow the kernel to do so as it usually does.) You
268: will lose the ability to use them for Emacs commands. Also, as a
269: consequence of using CBREAK mode, the terminal's Meta-key, if any,
270: will not work, and C-g will be liable to cause a loss of output which
271: will produce garbage on the screen. (These problems apply to 4.2BSD;
272: they may not happen in 4.3 or VMS, and I don't know what would happen
273: in sysV.) You can use keyboard-translate-table, as shown above,
274: to map two other input characters (such as C-^ and C-\) into C-s and
275: C-q, so that you can still search and quote.
276:
277: I have no intention of ever redisigning the Emacs command set for
278: the assumption that terminals use C-s/C-q flow control. This
279: flow control technique is a bad design, and terminals that need
280: it are bad merchandise and should not be purchased. If you can
281: get some use out of GNU Emacs on inferior terminals, I am glad,
282: but I will not make Emacs worse for properly designed systems
283: for the sake of inferior systems.
284:
285: * Control-S and Control-Q commands are ignored completely.
286:
287: For some reason, your system is using brain-damaged C-s/C-q flow
288: control despite Emacs's attempts to turn it off. Perhaps your
289: terminal is connected to the computer through a concentrator
290: that wants to use flow control.
291:
292: You should first try to tell the concentrator not to use flow control.
293: If you succeed in this, try making the terminal work without
294: flow control, as described in the preceding section.
295:
296: If that line of approach is not successful, map some other characters
297: into C-s and C-q using keyboard-translate-table. The example above
298: shows how to do this with C-^ and C-\.
299:
300: * Screen is updated wrong, but only on one kind of terminal.
301:
302: This could mean that the termcap entry you are using for that
303: terminal is wrong, or it could mean that Emacs has a bug handing
304: the combination of features specified for that terminal.
305:
306: The first step in tracking this down is to record what characters
307: Emacs is sending to the terminal. Execute the Lisp expression
308: (open-termscript "./emacs-script") to make Emacs write all
309: terminal output into the file ~/emacs-script as well; then do
310: what makes the screen update wrong, and look at the file
311: and decode the characters using the manual for the terminal.
312: There are several possibilities:
313:
314: 1) The characters sent are correct, according to the terminal manual.
315:
316: In this case, there is no obvious bug in Emacs, and most likely you
317: need more padding, or possibly the terminal manual is wrong.
318:
319: 2) The characters sent are incorrect, due to an obscure aspect
320: of the terminal behavior not described in an obvious way
321: by termcap.
322:
323: This case is hard. It will be necessary to think of a way for
324: Emacs to distinguish between terminals with this kind of behavior
325: and other terminals that behave subtly differently but are
326: classified the same by termcap; or else find an algorithm for
327: Emacs to use that avoids the difference. Such changes must be
328: tested on many kinds of terminals.
329:
330: 3) The termcap entry is wrong.
331:
332: See the file etc/TERMS for information on changes
333: that are known to be needed in commonly used termcap entries
334: for certain terminals.
335:
336: 4) The characters sent are incorrect, and clearly cannot be
337: right for any terminal with the termcap entry you were using.
338:
339: This is unambiguously an Emacs bug, and can probably be fixed
340: in termcap.c, tparam.c, term.c, scroll.c, cm.c or dispnew.c.
341:
342: * Output from Control-V is slow.
343:
344: On many bit-map terminals, scrolling operations are fairly slow.
345: Often the termcap entry for the type of terminal in use fails
346: to inform Emacs of this. The two lines at the bottom of the screen
347: before a Control-V command are supposed to appear at the top after
348: the Control-V command. If Emacs thinks scrolling the lines is fast,
349: it will scroll them to the top of the screen.
350:
351: If scrolling is slow but Emacs thinks it is fast, the usual reason is
352: that the termcap entry for the terminal you are using does not
353: specify any padding time for the `al' and `dl' strings. Emacs
354: concludes that these operations take only as much time as it takes to
355: send the commands at whatever line speed you are using. You must
356: fix the termcap entry to specify, for the `al' and `dl', as much
357: time as the operations really take.
358:
359: Currently Emacs thinks in terms of serial lines which send characters
360: at a fixed rate, so that any operation which takes time for the
361: terminal to execute must also be padded. With bit-map terminals
362: operated across networks, often the network provides some sort of
363: flow control so that padding is never needed no matter how slow
364: an operation is. You must still specify a padding time if you want
365: Emacs to realize that the operation takes a long time. This will
366: cause padding characters to be sent unnecessarily, but they do
367: not really cost much. They will be transmitted while the scrolling
368: is happening and then discarded quickly by the terminal.
369:
370: Most bit-map terminals provide commands for inserting or deleting
371: multiple lines at once. Define the `AL' and `DL' strings in the
372: termcap entry to say how to do these things, and you will have
373: fast output without wasted padding characters. These strings should
374: each contain a single %-spec saying how to send the number of lines
375: to be scrolled. These %-specs are like those in the termcap
376: `cm' string.
377:
378: You should also define the `IC' and `DC' strings if your terminal
379: has a command to insert or delete multiple characters. These
380: take the number of positions to insert or delete as an argument.
381:
382: A `cs' string to set the scrolling region will reduce the amount
383: of motion you see on the screen when part of the screen is scrolled.
384:
385: * You type Control-H (Backspace) expecting to delete characters.
386:
387: Put `stty dec' in your .login file and your problems will disappear
388: after a day or two.
389:
390: The choice of Backspace for erasure was based on confusion, caused by
391: the fact that backspacing causes erasure (later, when you type another
392: character) on most display terminals. But it is a mistake. Deletion
393: of text is not the same thing as backspacing followed by failure to
394: overprint. I do not wish to propagate this confusion by conforming
395: to it.
396:
397: For this reason, I believe `stty dec' is the right mode to use,
398: and I have designed Emacs to go with that. If there were a thousand
399: other control characters, I would define Control-h to delete as well;
400: but there are not very many other control characters, and I think
401: that providing the most mnemonic possible Help character is more
402: important than adapting to people who don't use `stty dec'.
403:
404: If you are obstinate about confusing buggy overprinting with deletion,
405: you can redefine Backspace in your .emacs file:
406: (global-set-key "\b" 'delete-backward-char)
407: You may then wish to put the function help-command on some
408: other key. I leave to you the task of deciding which key.
409:
410: * Editing files through RFS gives spurious "file has changed" warnings.
411: It is possible that a change in Emacs 18.37 gets around this problem,
412: but in case not, here is a description of how to fix the RFS bug that
413: causes it.
414:
415: Date: Wed, 28 Jan 87 15:18:40 EST
416: From: Bill Sommerfeld <[email protected]>
417: Sender: [email protected]
418: To: toddb%[email protected]
419: Cc: bug-rfs, [email protected]
420: Subject: Bug in RFS server (fsync())
421:
422: There was a serious pair of bugs in the handling of the fsync() system
423: call in the RFS server.
424:
425: The first is that the fsync() call is handled as another name for the
426: close() system call (!!). It appears that fsync() is not used by very
427: many programs; Emacs version 18 does an fsync() before closing files
428: to make sure that the bits are on the disk.
429:
430: This is fixed by the enclosed patch to the RFS server.
431:
432: The second, more serious problem, is that fsync() is treated as a
433: non-blocking system call (i.e., it's implemented as a message that
434: gets sent to the remote system without waiting for a reply). Fsync is
435: a useful tool for building atomic file transactions. Implementing it
436: as a non-blocking RPC call (when the local call blocks until the sync
437: is done) is a bad idea; unfortunately, changing it will break the RFS
438: protocol. Any suggestions?
439:
440: Bill Sommerfeld
441: MIT Project Athena
442:
443: (as always, your line numbers may vary)
444:
445: % rcsdiff -c -r1.2 serversyscall.c
446: RCS file: RCS/serversyscall.c,v
447: retrieving revision 1.2
448: diff -c -r1.2 serversyscall.c
449: *** /tmp/,RCSt1003677 Wed Jan 28 15:15:02 1987
450: --- serversyscall.c Wed Jan 28 15:14:48 1987
451: ***************
452: *** 163,169 ****
453: /*
454: * No return sent for close or fsync!
455: */
456: ! if (syscall == RSYS_close || syscall == RSYS_fsync)
457: proc->p_returnval = deallocate_fd(proc, msg->m_args[0]);
458: else
459: {
460: --- 166,172 ----
461: /*
462: * No return sent for close or fsync!
463: */
464: ! if (syscall == RSYS_close)
465: proc->p_returnval = deallocate_fd(proc, msg->m_args[0]);
466: else
467: {
468:
469: * ld complains because `alloca' is not defined on your system.
470:
471: Alloca is a library function in 4.2bsd, which is used very heavily by
472: GNU Emacs. Use of malloc instead is very difficult, as you would have
473: to arrange for the storage to be freed, and do so even in the case of
474: a longjmp happening inside a subroutine. Many subroutines in Emacs
475: can do longjmp.
476:
477: If your system does not support alloca, try defining the symbol
478: C_ALLOCA in the m-...h file for that machine. This will enable the use
479: in Emacs of a portable simulation for alloca. But you will find that
480: Emacs's performance and memory use improve if you write a true
481: alloca in assembler language.
482:
483: alloca (N) should return the address of an N-byte block of memory
484: added dynamically to the current stack frame.
485:
486: * Vax C compiler bugs affecting Emacs.
487:
488: You may get one of these problems compiling Emacs:
489:
490: foo.c line nnn: compiler error: no table entry for op STASG
491: foo.c: fatal error in /lib/ccom
492:
493: These are due to bugs in the C compiler; the code is valid C.
494: Unfortunately, the bugs are unpredictable: the same construct
495: may compile properly or trigger one of these bugs, depending
496: on what else is in the source file being compiled. Even changes
497: in header files that should not affect the file being compiled
498: can affect whether the bug happens. In addition, sometimes files
499: that compile correctly on one machine get this bug on another machine.
500:
501: As a result, it is hard for me to make sure this bug will not affect
502: you. I have attempted to find and alter these constructs, but more
503: can always appear. However, I can tell you how to deal with it if it
504: should happen. The bug comes from having an indexed reference to an
505: array of Lisp_Objects, as an argument in a function call:
506: Lisp_Object *args;
507: ...
508: ... foo (5, args[i], ...)...
509: putting the argument into a temporary variable first, as in
510: Lisp_Object *args;
511: Lisp_Object tem;
512: ...
513: tem = args[i];
514: ... foo (r, tem, ...)...
515: causes the problem to go away.
516: The `contents' field of a Lisp vector is an array of Lisp_Objects,
517: so you may see the problem happening with indexed references to that.
518:
519: * 68000 C compiler problems
520:
521: Various 68000 compilers have different problems.
522: These are some that have been observed.
523:
524: ** Using value of assignment expression on union type loses.
525: This means that x = y = z; or foo (x = z); does not work
526: if x is of type Lisp_Object.
527:
528: ** "cannot reclaim" error.
529:
530: This means that an expression is too complicated. You get the correct
531: line number in the error message. The code must be rewritten with
532: simpler expressions.
533:
534: ** XCONS, XSTRING, etc macros produce incorrect code.
535:
536: If temacs fails to run at all, this may be the cause.
537: Compile this test program and look at the assembler code:
538:
539: struct foo { char x; unsigned int y : 24; };
540:
541: lose (arg)
542: struct foo arg;
543: {
544: test ((int *) arg.y);
545: }
546:
547: If the code is incorrect, your compiler has this problem.
548: In the XCONS, etc., macros in lisp.h you must replace (a).u.val with
549: ((a).u.val + coercedummy) where coercedummy is declared as int.
550:
551: This problem will not happen if the m-...h file for your type
552: of machine defines NO_UNION_TYPE. That is the recommended setting now.
553:
554: * C compilers lose on returning unions
555:
556: I hear that some C compilers cannot handle returning
557: a union type. Most of the functions in GNU Emacs return
558: type Lisp_Object, which is currently defined as a union.
559:
560: This problem will not happen if the m-...h file for your type
561: of machine defines NO_UNION_TYPE. That is the recommended setting now.
562:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.