🚀 go-pugleaf

Hi:  thanks for your reply to my previous message.
To sum up, here's my previous message followed by your suggestions.

----------------------------------------------------------------------
> From zsd  Fri May 10 11:01:30 1991
> Subject: core dumps when emacs called from Mail & less

> System:  SGI Iris 3130 running Version 3.6
> gnu emacs: 18.57

> Problem 1:  when starting emacs from within less (v177) with
> the "v" command, one gets
>   Fatal error (11)./usr/local/bin/emacs: Segmentation violation -- Core dumped
> as a response.  Then one is back talking to less.

> Problem 2: when starting emacs from within Mail (version 5.2 6/21/85)
> one gets
>   Fatal error (11).Fatal error in "/usr/local/bin/emacs"
> as a response, and then the "(continue)" prompt from Mail.  Although
> the error message doesn't mention it in this case, a core file is
> created.

> Incidentally, problem (2) did NOT occur with emacs 18.55.


> If you (a) are interested in taking a look at this, and (b) don't have
> handy access to a 3130, I'd be happy to try out any tests that you
> care to suggest.

> 			Jim Diamond
> 			zsd@pig.drea.dnd.ca

----------------------------------------------------------------------
> From rms@gnu.ai.mit.edu  Thu May 16 18:29:21 1991
> Date: Thu, 16 May 91 16:22:50 -0400
> Subject: core dumps when emacs called from Mail & less

> Unfortunately, it doesn't crash for me.  However, since it is
> reproduceable, it might be easy to see from the coredump why it
> crashed.

> Also, you could first try setting your editor to echo, so that you can
> see what arguments these programs pass to Emacs.  Then try passing the
> same ones by hand.  Maybe that will crash too.  If it does, try again
> with a debugger.  That would probably crash too, and you can find out
> why.

Upon investigating this further, I find myself almost embarassed
enough to drop the whole issue, but since you may still be interested,
here goes:

I apparently did not test 18.57 on the 3130 after I built it.  (I
built it the same day as I build & tested it on an SGI 4D series
machine, and I now guess that I must have boldly assumed it was
working on the 3130!)  Having said the embarassing part, here's the poop.

Compiling 18.57 with -O (instead of -g) gives an emacs which just will
not run on my system.  If I use -g and not -O, I get one that works
well (but see summary point 2 below).  Here is the results of a
"where" from dbx on the object & core file:
---------------------------------------------
dbx version 3.99 of 12/19/87 21:33.
Type 'help' for help.
Corefile produced from file "eee"
reading symbolic information ...
[using memory image in core]
(dbx) where
_LFPERR(0xb) at 0x4238e
_LFPERR(0x305871c, 0x40587dc, 0x6) at 0x42537
Feval(0x5058714) at 0x2b3f9
Fprogn(0x505882c) at 0x2961b
funcall_lambda(0x5058834, 0x0, 0x1fffd9f0) at 0x2c023
apply_lambda() at 0x2be33
Feval(0x507cba4) at 0x2b4dd
top_level_2() at 0xdfdb
internal_condition_case(0xdfcc, 0x10744fc, 0xdc88) at 0x2a755
top_level_1(0x107440c) at 0xe00b
internal_catch(0x10744e8, 0xdfe2, 0x107440c) at 0x2a2ed
command_loop() at 0xdf57
recursive_edit_1() at 0xdc1d
Frecursive_edit() at 0xdbb7
main(0x1, 0x1fffdc18, 0x1fffdc20) at 0xd66b
start1() at 0x1043
---------------------------------------------

In summary:
1) using -O instead of -g causes problems in 18.57 on the 3130 that did
	not occur with 18.55
2) even with -g, emacs can't properly be called from less v.177 on
	this system.  When attempting to do so, after the file has
	been displayed on the screen, I get 
		select error: Socket operation on non-socket
	on the bottom line, a continuous stream of ^G's, and I have to
	kill the window, since I can't seem to find any other way to
	stop the ^G's.

Although I don't have the time to get right into the guts of things in
the hope of discovering what exactly is wrong, as I mentioned before
I'd be happy to try out any suggestions.


			Jim Diamond
			zsd@pig.drea.dnd.ca