[5231] in Athena Bugs

home help back first fref pref prev next nref lref last post

more on emacs malloc(-x)

daemon@ATHENA.MIT.EDU (John Carr)
Thu Jun 21 14:15:41 1990

To: bugs@ATHENA.MIT.EDU, wdc@ATHENA.MIT.EDU
Date: Thu, 21 Jun 90 06:21:46 EDT
From: John Carr <jfc@ATHENA.MIT.EDU>


A couple weeks ago I sent a pointer to a core dump where emacs was trying to
allocate a negative number of bytes.  I can now reproduce this.  When I
select a region in emacs (click left, right) and attempt to paste into an
andrew program such as ez or messages (middle button, select "paste"), emacs
attempts to allocate a negative size.  The andrew window hangs waiting on
the selection to be sent.  There are at least 2 bugs here:

	1. emacs calls malloc with a negative argument.  Since this only
	   happens when pasting into an andrew toolkit window, it seems
	   likely that the andrew toolkit is making an unreasonable request.
	   ("unreasonable" is not the same as "invalid" -- atk likes to
	   abuse the X window system).

	2. atk is waiting with an infinite timeout for emacs to return the
	   selection (it provides a menu in response to middle button clicks
	   while waiting, but the menu options do nothing).  The only way
	   out is to kill the process or the window.

If I remember the ICCCM correctly, it provides no mechanism for graceful
handling of client death while that client has unhandled selection requests.

This happens reliably on a VAX to my RT display.  I could not get it to
happen running emacs locally; it did happen running emacs from another RT.
In that case, I typed a few hundred characters into the minibuffer and
started selecting and trying to paste.  The first few tries had no effect on
the ez window I was pasting into and did not hang emacs.  About the 5th
attempt hung emacs (ps said process size was 5 megabytes).


home help back first fref pref prev next nref lref last post