gnus: apparently kills external viewers too aggressively

gnus: apparently kills external viewers too aggressively

[Manoj Srivastava]

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

Gnus v5.10.2
GNU Emacs 21.3.2 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2003-04-24 on raven, modified by Debian
200 news.vmware.com InterNetNews NNRP server INN 1.7.2 08-Dec-1997 ready (posting ok).

Hi,

	[Please retain the CC to 200823-forwarded@bugs.debian.org in           
         your response, so that the Debian bug tracking system as a             
         record of your input]                                                  
                                                                                
         This bug was reported by a Debian user

In gnus under 'emacs -nw' running in an xterm, to view an image/jpeg
MIME attacment, gnus launches 'display XXXX.jpeg' which opens up an
imagemagick window containing the image.

If I close that imagemagick window directly, there's no problem; but
if I let gnus close it (by, e.g., hitting ENTER again on the
image/jpeg line in the mail message, or by hitting 'n' to go to the
next message, or 'q' to leave the current group) gnus apparently kills
the imagemagick ('display') process too aggressively, causing it to
leave two shared memory segments allocated.

Do this enough times and you eventually run out of swap space.  Even
after gnus and emacs and X have been successfully stopped, the shared
memory segments are still there ('ipcs -m' shows them; 'ipcrm -m ...'
successfully removes them).

Maybe this is a bug in imagemagick, but I suspect gnus is sending it
SIGKILL instead of SIGTERM, or something to that effect.  I have not
looked at the source code.

Let me know if you need more info, or if I can help in any way.
Thanks.



[-- Attachment #2: User settings --]
[-- Type: application/emacs-lisp, Size: 19061 bytes --]

[-- Attachment #3: Type: text/plain, Size: 405 bytes --]

-- 
A brahmin is called so by breaking with evil deeds. It is by pious
behaviour that a man is called a man of religion, and by casting out
blemishes one is called one gone forth. 388
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: gnus: apparently kills external viewers too aggressively

[Simon Josefsson]

Manoj Srivastava <srivasta@debian.org> writes:

> If I close that imagemagick window directly, there's no problem; but
> if I let gnus close it (by, e.g., hitting ENTER again on the
> image/jpeg line in the mail message, or by hitting 'n' to go to the
> next message, or 'q' to leave the current group) gnus apparently kills
> the imagemagick ('display') process too aggressively, causing it to
> leave two shared memory segments allocated.
>
> Do this enough times and you eventually run out of swap space.  Even
> after gnus and emacs and X have been successfully stopped, the shared
> memory segments are still there ('ipcs -m' shows them; 'ipcrm -m ...'
> successfully removes them).
>
> Maybe this is a bug in imagemagick, but I suspect gnus is sending it
> SIGKILL instead of SIGTERM, or something to that effect.  I have not
> looked at the source code.
>
> Let me know if you need more info, or if I can help in any way.

Can you strace or gdb display to see what signal it receives?  Or
perhaps simply start display on the command line and see if it leaves
a shared segment around if you SIGKILL or SIGTERM it?

Without knowing much about ipc shared memory segments, I'd say this is
a bug somewhere else.  I think it could be useful to ask the
imagemagick developers.

Re: gnus: apparently kills external viewers too aggressively

[David Coe]

Simon Josefsson <jas@extundo.com> writes:

> Can you strace or gdb display to see what signal it receives?  Or
> perhaps simply start display on the command line and see if it leaves
> a shared segment around if you SIGKILL or SIGTERM it?

Yes, display does leave the segments allocated when it's SIGKILLed,
and doesn't when it's SIGTERMed.  See Debian Bug#207379 against
imagemagick ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=207379 ).  
shmctl(2) does say that the creator of a segment *must* ensure
that the segment is eventually destroyed, so this does look like a bug
in imagemagick.

I don't know whether it would be too much overhead for
gnus to try SIGTERM before SIGKILL; I leave that up to you --
as I'm sure you know, many programs don't (or can't) clean up after 
themselves as well as they should when KILLed.

Thanks for gnus!

Re: gnus: apparently kills external viewers too aggressively

[Simon Josefsson]

David Coe <davidc@debian.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Can you strace or gdb display to see what signal it receives?  Or
>> perhaps simply start display on the command line and see if it leaves
>> a shared segment around if you SIGKILL or SIGTERM it?
>
> Yes, display does leave the segments allocated when it's SIGKILLed,
> and doesn't when it's SIGTERMed.  See Debian Bug#207379 against
> imagemagick ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=207379 ).  
> shmctl(2) does say that the creator of a segment *must* ensure
> that the segment is eventually destroyed, so this does look like a bug
> in imagemagick.
>
> I don't know whether it would be too much overhead for
> gnus to try SIGTERM before SIGKILL; I leave that up to you --
> as I'm sure you know, many programs don't (or can't) clean up after 
> themselves as well as they should when KILLed.

Makes sense, the patch below has been installed.  It tries to
interrupt the process in a loop with a echo area message, and when it
is dead, or you press C-g, it goes on and send it a final KILL and
remove the files.

Still, display seem to leave some memory around.  Starting display
allocates some buffers:

--- foo Wed Aug 27 03:40:41 2003
+++ bar Wed Aug 27 03:40:46 2003
@@ -37,6 +37,9 @@
 0x00000000 16515107   jas       777        7680000    0
 0x00000000 16547876   jas       777        262144     0
 0x00000000 16580645   jas       777        27648      0
+0x00000000 16810022   jas       777        7680000    2
+0x00000000 16842791   jas       777        262144     2
 0x00000000 16678952   jas       777        27648      0
 0x00000000 16777257   jas       777        27648      0
+0x00000000 16875562   jas       777        27648      2

Killing display cleanly removes some buffers, but not all:

--- foo Wed Aug 27 03:40:41 2003
+++ baz Wed Aug 27 03:40:51 2003
@@ -39,4 +39,5 @@
 0x00000000 16580645   jas       777        27648      0
 0x00000000 16678952   jas       777        27648      0
 0x00000000 16777257   jas       777        27648      0
+0x00000000 16875562   jas       777        27648      0

I'd say it is an ImageMagick bug.

2003-08-27  Simon Josefsson  <jas@extundo.com>

	* mm-decode.el (mm-remove-part): Try to kill external displayers
	cleanly first (if it refuses, C-g aborts loop and kill process
	unconditionally).  Also make sure process is dead before we remove
	the files it may be using.  Reported by David Coe
	<davidc@debian.org>.

Index: mm-decode.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/mm-decode.el,v
retrieving revision 6.92
retrieving revision 6.93
diff -u -p -r6.92 -r6.93
--- mm-decode.el	8 Jul 2003 15:28:27 -0000	6.92
+++ mm-decode.el	27 Aug 2003 01:49:26 -0000	6.93
@@ -844,9 +844,17 @@ external if displayed external."
 	  (funcall object))
 	 ;; Externally displayed part.
 	 ((consp object)
+	  (condition-case ()
+	      (while (get-buffer-process (cdr object))
+		(interrupt-process (get-buffer-process (cdr object)))
+		(message "Waiting for external displayer to die...")
+		(sit-for 1))
+	    (quit)
+	    (error))
+	  (ignore-errors (and (cdr object) (kill-buffer (cdr object))))
 	  (ignore-errors (delete-file (car object)))
-	  (ignore-errors (delete-directory (file-name-directory (car object))))
-	  (ignore-errors (and (cdr object) (kill-buffer (cdr object)))))
+	  (ignore-errors (delete-directory (file-name-directory
+					    (car object)))))
 	 ((bufferp object)
 	  (when (buffer-live-p object)
 	    (kill-buffer object)))))

Re: gnus: apparently kills external viewers too aggressively

[David Coe]

Simon Josefsson <jas@extundo.com> writes:

> Makes sense, the patch below has been installed.  It tries to
> interrupt the process in a loop with a echo area message, and when it
> is dead, or you press C-g, it goes on and send it a final KILL and
> remove the files.

Thanks.  That works nicely, but the message "Waiting for external
displayer to die..." doesn't go away (until user does something, like
select the next message).  The external display process does get
stopped correctly (and it does destroy the shared segments it had
allocated), but the message implies to the user that gnus is still
waiting.

Is there a better way to deal with that message, or do we have a bug
somewhere else? (Perhaps I or debian gnus/emacs have something wrong.)

> Still, display seem to leave some memory around.  Starting display
> allocates some buffers:
[...]

> Killing display cleanly removes some buffers, but not all:
[...]

That doesn't happen here; maybe that other segment is created by
something else?  'ipcs -p' will show you the creator (and last
accessor) processes; not important, unless you're interested.

Thanks again.

Re: gnus: apparently kills external viewers too aggressively

[Simon Josefsson]

David Coe <davidc@debian.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Makes sense, the patch below has been installed.  It tries to
>> interrupt the process in a loop with a echo area message, and when it
>> is dead, or you press C-g, it goes on and send it a final KILL and
>> remove the files.
>
> Thanks.  That works nicely, but the message "Waiting for external
> displayer to die..." doesn't go away (until user does something, like
> select the next message).  The external display process does get
> stopped correctly (and it does destroy the shared segments it had
> allocated), but the message implies to the user that gnus is still
> waiting.
>
> Is there a better way to deal with that message, or do we have a bug
> somewhere else? (Perhaps I or debian gnus/emacs have something wrong.)

I have installed the fix below too.  Thanks for testing.

--- mm-decode.el.~6.93.~	Thu Jan  1 01:00:01 1970
+++ mm-decode.el	Wed Aug 27 08:01:16 2003
@@ -852,6 +852,7 @@
 	    (quit)
 	    (error))
 	  (ignore-errors (and (cdr object) (kill-buffer (cdr object))))
+	  (message "Waiting for external displayer to die...done")
 	  (ignore-errors (delete-file (car object)))
 	  (ignore-errors (delete-directory (file-name-directory
 					    (car object)))))