From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/53834 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus: apparently kills external viewers too aggressively Date: Wed, 27 Aug 2003 03:47:02 +0200 Sender: ding-owner@lists.math.uh.edu Message-ID: References: <87vfss42ij.fsf@glaurung.green-gryphon.com> <86k790b8rp.fsf@someotherplace.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1061948862 30715 80.91.224.253 (27 Aug 2003 01:47:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 27 Aug 2003 01:47:42 +0000 (UTC) Cc: David Coe , bugs@gnus.org (The Gnus Bugfixing Girls + Boys), ding@gnus.org, 200823-forwarded@bugs.debian.org Original-X-From: ding-owner+M2374@lists.math.uh.edu Wed Aug 27 03:47:39 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19rpPP-0002RM-00 for ; Wed, 27 Aug 2003 03:47:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19rpPA-0003ne-00; Tue, 26 Aug 2003 20:47:24 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19rpP5-0003nZ-00 for ding@lists.math.uh.edu; Tue, 26 Aug 2003 20:47:19 -0500 Original-Received: (qmail 22928 invoked by alias); 27 Aug 2003 01:47:19 -0000 Original-Received: (qmail 22919 invoked from network); 27 Aug 2003 01:47:19 -0000 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net (HELO yxa.extundo.com) (217.13.230.178) by sclp3.sclp.com with SMTP; 27 Aug 2003 01:47:19 -0000 Original-Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h7R1l3dk016514 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 27 Aug 2003 03:47:09 +0200 Original-To: David Coe Mail-Copies-To: nobody X-Payment: hashcash 1.2 0:030827:davidc@debian.org:59c1ed3aef880a6a X-Hashcash: 0:030827:davidc@debian.org:59c1ed3aef880a6a X-Payment: hashcash 1.2 0:030827:david@someotherplace.org:a9a18ba0dca90b42 X-Hashcash: 0:030827:david@someotherplace.org:a9a18ba0dca90b42 X-Payment: hashcash 1.2 0:030827:bugs@gnus.org:b64e0a7c9aa3874f X-Hashcash: 0:030827:bugs@gnus.org:b64e0a7c9aa3874f X-Payment: hashcash 1.2 0:030827:ding@gnus.org:361e84ed1bea9ea4 X-Hashcash: 0:030827:ding@gnus.org:361e84ed1bea9ea4 X-Payment: hashcash 1.2 0:030827:200823-forwarded@bugs.debian.org:e0494862dc0d92c6 X-Hashcash: 0:030827:200823-forwarded@bugs.debian.org:e0494862dc0d92c6 In-Reply-To: <86k790b8rp.fsf@someotherplace.org> (David Coe's message of "Tue, 26 Aug 2003 13:58:50 -0400") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:53834 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:53834 David Coe writes: > Simon Josefsson 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 * 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 . 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)))))