aaa@mtuni.ATT.COM (Aaron Akman) (12/30/87)
I am trying to port GNU to a 386 running UNIX. So far, I have been
fairly successful. I am able to bring up emacs, and do standard
editing kinds of things. I have encountered one problem so far:
In certain situations, I get a "Fatal error(11)." and it dumps core.
Here's what I can say about the symptoms:
1. It always seems to happen when I am hitting <Return> in the
minibuffer.
2. An attempt at stack back-tracing showed:
kill() has no subroutine linkage (pushl)
Maybe kill(...) from fatal_error_signal(..) [emacs.c]
Maybe kill() from update_line(..) [dispnew.c]
fatal_error_signal(..) [emacs.c]
concat(...) [fns.c]
(...and much more.)
3. One certain case is: (1) I load *info* (C-h i), (2) ask about a
variable (C-h v), (3) type in the variable name
("mode-line-inverse-video"), and (4) hit return. Core dumped.
Any ideas?
--
Aaron, mtuni!aaa, 201-957-2751chip@ateng.UUCP (Chip Salzenberg) (12/31/87)
In article <303@mtuni.ATT.COM> aaa@mtuni.ATT.COM (Aaron Akman) writes: }I am trying to port GNU to a 386 running UNIX. [...] }In certain situations, I get a "Fatal error(11)." and it dumps core. } }2. An attempt at stack back-tracing showed: } } kill() has no subroutine linkage (pushl) } Maybe kill(...) from fatal_error_signal(..) [emacs.c] } Maybe kill() from update_line(..) [dispnew.c] } fatal_error_signal(..) [emacs.c] } concat(...) [fns.c] } (...and much more.) Perhaps you're calling concat() with a NULL pointer. Although many versions of UNIX have a zero at logical location zero, not all do. It could be that your '386 Unix doesn't have it, so a reference to NULL is illegal. Or you could be overflowing your stack. -- Chip Salzenberg UUCP: "{codas,uunet}!ateng!chip" A T Engineering My employer's opinions are a trade secret. Chip's Observation: "Anything that works is better than anything that doesn't."
dougm@ico.UUCP (Doug McCallum) (12/31/87)
You don't say which version of GNU emacs you are trying to port. I've had 18.44 up for some time with no problems. I had the same problems you are seeing with 18.42. There is a bug in the optimizer for the compiler which botched the fns.c file. Compiling it without optimization eliminated the problem. fns.c appears to be reorganized since then and doesn't aggravate the problem. If you are running a later version, you shouldn't have the problem.
allbery@axcess.UUCP (Brandon S. Allbery) (01/04/88)
Altos's 386 *nixes will fault any program attempting to address within the first 80K(?) of its address space. Rather bogus, if you ask me; what did they hide there, the upage? -- ___ ________________, Brandon S. Allbery cbosgd \ ' \/ __ __, __, aXcess Company mandrill| __ | /__> <__ <__ 6615 Center St. #A1-105 !ncoast! / ` | \__. .__> .__> Mentor, OH 44060-4101 necntc | axcess!allbery \___/\________________. Moderator, comp.sources.misc hoptoad/