From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 04 05:16:55 2012 Received: (at submit) by debbugs.gnu.org; 4 Dec 2012 10:16:55 +0000 Received: from localhost ([127.0.0.1]:52478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TfpYc-00049w-GX for submit@debbugs.gnu.org; Tue, 04 Dec 2012 05:16:55 -0500 Received: from eggs.gnu.org ([208.118.235.92]:58123) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TfpYZ-00049o-PN for submit@debbugs.gnu.org; Tue, 04 Dec 2012 05:16:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TfpW5-0003d7-Mt for submit@debbugs.gnu.org; Tue, 04 Dec 2012 05:14:24 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:54563) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfpW5-0003d0-Ja for submit@debbugs.gnu.org; Tue, 04 Dec 2012 05:14:17 -0500 Received: from eggs.gnu.org ([208.118.235.92]:52178) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfpVx-0005o7-Ik for bug-gnu-emacs@gnu.org; Tue, 04 Dec 2012 05:14:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tfnnl-0003pF-Fa for bug-gnu-emacs@gnu.org; Tue, 04 Dec 2012 03:24:32 -0500 Received: from mail-lb0-f169.google.com ([209.85.217.169]:42799) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfnTy-0008U4-Jt for bug-gnu-emacs@gnu.org; Tue, 04 Dec 2012 03:03:59 -0500 Received: by mail-lb0-f169.google.com with SMTP id gk1so3322276lbb.0 for ; Tue, 04 Dec 2012 00:03:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2nRyH1MHjfcKAvPH9tq/rIer8xyKHhQQ9GfWnFr2CXE=; b=HFePFfFkQct1zVCo59dzgfrtUO/bK1Z8LxJf6MFVHknANM8+wAOpEfthZlAVBlkI6K rznmplCCTYoNm1qBBNGngto6D+TcMxeNMuvLuMTqIWMzfBW1ps6SP+xkOIwDjpQPWSHp CpeepbQ0ecTWeH0OqdEPU68TT7gHA4e4anmWJM+IwjnO26qZAgSl9fbliyajKyktgmNJ XPQp+fPTyvHGRTNfAEVJAxD6eWFXhc7b8jq78FSKslaeT/mwZ6H926u1qlCucC88j27R RslT4OdbmRCA+mv9XZIyFw/+zsTZbSWcNe0nGjhiw7ThlHqWam/N1X1TCVn11ZWe+0D6 Si2Q== MIME-Version: 1.0 Received: by 10.112.24.104 with SMTP id t8mr5420016lbf.134.1354608236680; Tue, 04 Dec 2012 00:03:56 -0800 (PST) Received: by 10.114.22.167 with HTTP; Tue, 4 Dec 2012 00:03:56 -0800 (PST) Date: Tue, 4 Dec 2012 16:03:56 +0800 Message-ID: Subject: 24.3.50; Emacs cannot create subprocess From: Li Zhai To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -6.1 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) Hi, I've noticed emacs cannot create subprocess in some cases: (progn (dotimes (i 25) (call-process-region (point-min) (point-min) "ddeclient" t 0 nil "SUMATRA" "control") (message "%d" i))) After executed above codes, emacs report: "Spawning child process" "resource temporarily unavailable" My emacs running environment as follows: In GNU Emacs 24.3.50.1 (i386-mingw-nt6.1.7601) of 2012-11-30 on ALAN-NB Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --with-gcc (4.5) --cflags -I/ImageLib/giflib-4.1.6/lib -I/ImageLib/zlib-1.2.5 -I/ImageLib/libpng-1.4.5 -I/ImageLib/jpeg-8c -I/ImageLib/libxpm-3.5.8-w32-src/src -I/ImageLib/libxpm-3.5.8-w32-src/include -I/ImageLib/tiff-3.9.4/libtiff -I/ImageLib/libxml2-2.8.0/include -I/ImageLib/gnutls-3.0.20-w32/include' Important settings: value of $LANG: zh_CN.GBK locale-coding-system: cp936 default enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: eldoc-mode: t paredit-mode: t TeX-PDF-mode: t savehist-mode: t desktop-save-mode: t anything-dired-mode: Enable anything completion in Dired functions. Bindings affected are C, R, S, H. This is deprecated for Emacs24+ users, use `ac-mode' instead. shell-dirtrack-mode: t show-paren-mode: t recentf-mode: t delete-selection-mode: t auto-image-file-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t size-indication-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t hs-minor-mode: t Recent input: C-p C-p C-n M-m ; ; C-n C-n C-n C-w C-p C-p C-p C-y C-p C-n C-n C-e C-x C-e C-x q q C-x C-e q C-x C-e q M-x b u g C-g b u g . * r e p o r t C-a C-e e m a c s C-a e m a c s . * C-n C-x 1 C-c C-k C-g C-c C-c n C-x 1 C-/ C-/ C-/ C-/ C-x k C-x C-b a a q M-x M-p X b C-g C-x b s c r C-x b C-g C-h e M-> C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p M-v C-s s w a n C-s C-s C-g C-g C-x b C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-e C-x C-e M-w q C-x b C-g M-x M-p Recent messages: Mark set byte-code: Beginning of buffer [6 times] Auto-saving...done Undo! [3 times] user-error: No further undo information Quit [2 times] Mark set Quit Entering debugger... Back to top level. Quit Load-path shadows: None found. Features: (shadow sort mail-extr gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime dig gnus-sum nnoo gnus-group gnus-undo nnmail mail-source gnus-start gnus-spec gnus-int gnus-range gnus-win gnus gnus-ems nnheader emacsbug message rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils novice highlight-symbol hi-lock misearch multi-isearch vc-git bm bs macros help-mode debug rect hideshow eldoc paredit ind-util reftex-auc preview prv-emacs info reporter tex-buf tex-fold cdlatex texmathp reftex-dcr reftex reftex-vars font-latex latex derived tex-style tex savehist desktop saveplace bbdb-autoloads bbdb timezone preview-latex tex-site auto-loads org-clock org-exp ob-exp org-exp-blocks org-agenda w32-browser anything-config browse-url imenu bookmark pp rx anything-match-plugin semantic/util-modes semantic/util semantic semantic/tag semantic/lex semantic/fw loaddefs mode-local cedet org ob-tangle ob-ref ob-lob ob-table org-footnote org-src ob-comint ob-keys org-pcomplete org-list org-faces org-entities noutline outline org-version ob-emacs-lisp ob org-compat org-macs ob-eval org-loaddefs xml grep compile tramp tramp-compat tramp-loaddefs shell pcomplete comint format-spec dired-x dired-aux anything smart-compile paren slime-autoloads cc-styles cc-align cc-engine cc-vars cc-defs xcscope ring auto-install easy-mmode ffap thingatpt find-func dired url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util url-parse auth-source eieio gnus-util mm-util mail-prsvr password-cache url-vars mailcap windmove cal-china-x cl-macs gv cl cl-lib cal-china lunar solar cal-dst holidays hol-loaddefs cal-menu calendar cal-loaddefs window+ uniquify midnight filecache ido recentf tree-widget wid-edit easymenu edmacro kmacro byte-opt warnings bytecomp byte-compile cconv nadvice advice help-fns server ps-ccrypt delsel image-file avoid ansi-color time-date china-util tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process w32 multi-tty emacs) From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 04 15:24:17 2012 Received: (at 13079) by debbugs.gnu.org; 4 Dec 2012 20:24:17 +0000 Received: from localhost ([127.0.0.1]:53662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tfz2P-0003dg-2q for submit@debbugs.gnu.org; Tue, 04 Dec 2012 15:24:17 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:32807) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tfz2M-0003dX-5t for 13079@debbugs.gnu.org; Tue, 04 Dec 2012 15:24:15 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MEI00500WBEEH00@a-mtaout21.012.net.il> for 13079@debbugs.gnu.org; Tue, 04 Dec 2012 22:23:32 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MEI00520WN8AA60@a-mtaout21.012.net.il>; Tue, 04 Dec 2012 22:23:32 +0200 (IST) Date: Tue, 04 Dec 2012 22:23:31 +0200 From: Eli Zaretskii Subject: Re: bug#13079: 24.3.50; Emacs cannot create subprocess In-reply-to: X-012-Sender: halo1@inter.net.il To: Li Zhai Message-id: <83ehj5r2gs.fsf@gnu.org> References: X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Tue, 4 Dec 2012 16:03:56 +0800 > From: Li Zhai > > I've noticed emacs cannot create subprocess in some cases: > > (progn > (dotimes (i 25) > (call-process-region (point-min) (point-min) "ddeclient" t 0 nil > "SUMATRA" "control") > (message "%d" i))) > > After executed above codes, emacs report: > > "Spawning child process" "resource temporarily unavailable" [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 13079 Cc: 13079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Tue, 4 Dec 2012 16:03:56 +0800 > From: Li Zhai > > I've noticed emacs cannot create subprocess in some cases: > > (progn > (dotimes (i 25) > (call-process-region (point-min) (point-min) "ddeclient" t 0 nil > "SUMATRA" "control") > (message "%d" i))) > > After executed above codes, emacs report: > > "Spawning child process" "resource temporarily unavailable" [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4993] > Date: Tue, 4 Dec 2012 16:03:56 +0800 > From: Li Zhai > > I've noticed emacs cannot create subprocess in some cases: > > (progn > (dotimes (i 25) > (call-process-region (point-min) (point-min) "ddeclient" t 0 nil > "SUMATRA" "control") > (message "%d" i))) > > After executed above codes, emacs report: > > "Spawning child process" "resource temporarily unavailable" I cannot reproduce this here. Does this happen in "emacs -Q"? Also, what do you mean "after executing"? Does it mean Emacs displays this message before it ends the loop, i.e. before it launches 25 processes? Or do you mean that after all the 25 processes are launched, Emacs cannot start more subprocesses? If the latter, does the problem go away after you wait for all the 25 ddeclient subprocesses to exit? From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 04 21:27:03 2012 Received: (at 13079) by debbugs.gnu.org; 5 Dec 2012 02:27:03 +0000 Received: from localhost ([127.0.0.1]:53920 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tg4hT-000517-7a for submit@debbugs.gnu.org; Tue, 04 Dec 2012 21:27:03 -0500 Received: from mail-la0-f44.google.com ([209.85.215.44]:35410) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tg4hQ-00050h-CZ for 13079@debbugs.gnu.org; Tue, 04 Dec 2012 21:27:01 -0500 Received: by mail-la0-f44.google.com with SMTP id d3so4029847lah.3 for <13079@debbugs.gnu.org>; Tue, 04 Dec 2012 18:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6vQl+JLIubWQagOoxDnd4OH0V+QUpA2e4ykvaU15VCg=; b=Ms/m0B/Olbjt7EsTzr9u0qfpfnFs7ZIXwJ5/OV4Cm+jRde+wTF4AiUgKFxVQ8TjheM nqZLxo8Pf8GeEcvhgG8yVMNClWhJN1cEP2vqLtQlzrt6wadzmCd1u88ob8gQS0VYqUYS +ewrlq7488fYenLFRw/q5ybtgdw4QtnhyxAlnaQYWFXoxfcwxZpxlbjWmfmazQxDoBWn YzyOuMj/PLEoqw3qsyX1P9OBaGw28AeWfpI7JhA4jh05FPHewxapegjdFDWh/feQaAaX QQMy3TwOxQtWK8ePTH+ZQpoqLPNFN3kBKPBEudXgIQJVzG4y2rjYHGQZqu7qOL1UvDyA qYrA== MIME-Version: 1.0 Received: by 10.152.108.42 with SMTP id hh10mr14971059lab.4.1354674411939; Tue, 04 Dec 2012 18:26:51 -0800 (PST) Received: by 10.114.22.167 with HTTP; Tue, 4 Dec 2012 18:26:51 -0800 (PST) In-Reply-To: <83ehj5r2gs.fsf@gnu.org> References: <83ehj5r2gs.fsf@gnu.org> Date: Wed, 5 Dec 2012 10:26:51 +0800 Message-ID: Subject: Re: bug#13079: 24.3.50; Emacs cannot create subprocess From: Li Zhai To: Eli Zaretskii Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13079 Cc: 13079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) Sorry. I'll explain more clear. I'm using emacs under windows 7. I mean, emacs display the messages before the loop ends. And all the processes are gone, emacs did not wait them to exit. I've tried two different version from http://ftp.gnu.org/gnu/emacs/windows/emacs-23.4-bin-i386.zip and http://alpha.gnu.org/gnu/emacs/windows/emacs-20120917-r110062-bin-i386.zip Here is how to reproduce the bug: 1. Open the emacs using ``emacs -Q'' 2. paste the code into *scratch* buffer: (progn (dotimes (i 35) (call-process-region (point-min) (point-min) "ddeclient" t 0 nil "SUMATRA" "control") (message "%d" i))) the *ONLY* difference between the previous code is I increase the repeat times to call the function `call-process-region'. Here is 35 times, you could try to increase the number lager if the bug not reproducing. 3. Eval the code using C-x C-e 4. You should see the emacs report an error: Debugger entered--Lisp error: (file-error "Spawning child process" "resource temporarily unavailable") 5. Quit the elisp debugger and execute the code again(press C-x C-e), this time emacs should report: Debugger entered--Lisp error: (file-error "Opening output file" "permission denied" "c:/Users/iot003/Desktop/emacs-24.2.50/bin") call-process-region(1 1 "ddeclient" t 0 nil "SUMATRA" "control") 6. Quit the elisp debugger. This time, emacs cannot create any sub-process any more. Try to execute a shell command by press `M-! ls', you will find it out. This problem occurred more often on my private build version. I guess the problem is the default stack size assigned by compiler is too small. Thanks for your reply, Eli. Have a good day. On Wed, Dec 5, 2012 at 4:23 AM, Eli Zaretskii wrote: >> Date: Tue, 4 Dec 2012 16:03:56 +0800 >> From: Li Zhai >> >> I've noticed emacs cannot create subprocess in some cases: >> >> (progn >> (dotimes (i 25) >> (call-process-region (point-min) (point-min) "ddeclient" t 0 nil >> "SUMATRA" "control") >> (message "%d" i))) >> >> After executed above codes, emacs report: >> >> "Spawning child process" "resource temporarily unavailable" > > I cannot reproduce this here. Does this happen in "emacs -Q"? > Also, what do you mean "after executing"? Does it mean Emacs displays > this message before it ends the loop, i.e. before it launches 25 > processes? Or do you mean that after all the 25 processes are > launched, Emacs cannot start more subprocesses? If the latter, does > the problem go away after you wait for all the 25 ddeclient > subprocesses to exit? From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 05 12:30:20 2012 Received: (at 13079) by debbugs.gnu.org; 5 Dec 2012 17:30:20 +0000 Received: from localhost ([127.0.0.1]:55226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgInc-0004LO-7g for submit@debbugs.gnu.org; Wed, 05 Dec 2012 12:30:20 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:41919) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgInX-0004LC-QN for 13079@debbugs.gnu.org; Wed, 05 Dec 2012 12:30:17 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MEK00C00IFXG600@a-mtaout21.012.net.il> for 13079@debbugs.gnu.org; Wed, 05 Dec 2012 19:29:59 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MEK00CMLJ9X9LB0@a-mtaout21.012.net.il>; Wed, 05 Dec 2012 19:29:57 +0200 (IST) Date: Wed, 05 Dec 2012 19:29:58 +0200 From: Eli Zaretskii Subject: Re: bug#13079: 24.3.50; Emacs cannot create subprocess In-reply-to: X-012-Sender: halo1@inter.net.il To: Li Zhai Message-id: <83wqwwpfu1.fsf@gnu.org> References: <83ehj5r2gs.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Wed, 5 Dec 2012 10:26:51 +0800 > From: Li Zhai > Cc: 13079@debbugs.gnu.org > > I mean, emacs display the messages before the loop ends. And all the > processes are gone, emacs did not wait them to exit. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 13079 Cc: 13079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Wed, 5 Dec 2012 10:26:51 +0800 > From: Li Zhai > Cc: 13079@debbugs.gnu.org > > I mean, emacs display the messages before the loop ends. And all the > processes are gone, emacs did not wait them to exit. Emacs doesn't wait because you told it so, by using zero as the 5th argument to call-process-region. This is normal. > I've tried two different version from > http://ftp.gnu.org/gnu/emacs/windows/emacs-23.4-bin-i386.zip and > http://alpha.gnu.org/gnu/emacs/windows/emacs-20120917-r110062-bin-i386.zip > > Here is how to reproduce the bug: > > 1. Open the emacs using ``emacs -Q'' > > 2. paste the code into *scratch* buffer: > > (progn > (dotimes (i 35) > (call-process-region (point-min) (point-min) "ddeclient" t 0 nil > "SUMATRA" "control") > (message "%d" i))) > > the *ONLY* difference between the previous code is I increase the > repeat times to call the function `call-process-region'. Here is 35 > times, you could try to increase the number lager if the bug not > reproducing. > > 3. Eval the code using C-x C-e > > 4. You should see the emacs report an error: > > Debugger entered--Lisp error: (file-error "Spawning child process" > "resource temporarily unavailable") This is not a bug, but a known limitation of Emacs on Windows. The way management of subprocesses is implemented on Windows, Emacs can only have 32 subprocesses simultaneously at any given time (because it watches two separate handles for each subprocess, and uses an API that supports maximum of 64 handles). So this is also normal. If you use 32 instead of 35, the above error message will not appear. But that won't solve the _real_ problem here, see below. > 5. Quit the elisp debugger and execute the code again(press C-x C-e), > this time emacs should report: > > Debugger entered--Lisp error: (file-error "Opening output file" > "permission denied" "c:/Users/iot003/Desktop/emacs-24.2.50/bin") > call-process-region(1 1 "ddeclient" t 0 nil "SUMATRA" "control") > > 6. Quit the elisp debugger. This time, emacs cannot create any > sub-process any more. Try to execute a shell command by press `M-! > ls', you will find it out. > > This problem occurred more often on my private build version. I guess > the problem is the default stack size assigned by compiler is too > small. No, this has nothing to do with something fancy like stack size, it's a much more mundane problem. It's because we fail to create temporary files needed by call-process-region and commands that use it. Did you look in your TEMP directory? I bet you have gobs of emXYZZY files there, exactly 42 of them per each time you tried this stuff. The immediate reason for the mysterious "permission denied" error (about a directory!) is that call-process-region was not checking whether the call to 'mktemp' failed. When that function fails, it produces an empty "file name", and call-process-region was boldly using that as a file name, eventually trying to open a directory, which on Windows fails with EACCES. This part was easy to fix: starting with revision 110996 on the emacs-24 branch, Emacs now produces a more intelligent error message in this case. The harder part of this bug is the reason _why_ 'mktemp' fails. Your command launches asynchronous subprocesses, creating a temporary file for each one of them where Emacs puts the contents of the region. In this case, call-process-region arranges for the temporary files to be removed when the call to call-process returns, and then calls call-process. However, since this is an async subprocess, call-process returns immediately, without waiting for the subprocess to exit, and Emacs deletes the temporary file. This "cleanup" uses the non-portable (outside of Posix filesystems) trick of deleting a file while it is still open and used by the child process. On Windows, this attempt to delete the file fails, and the file is left behind. The other part of this puzzle is that 'mktemp' as implemented by the Windows runtime can only have up to 42 simultaneous temporary files per calling thread (the MSDN documentation says 26, but that's a lie). Once there are 42 files in your TEMP directory created by a single Emacs session, all the future calls to 'mktemp' from the same session will fail, unless you manually delete those files. This part of the bug is harder to solve, because some code needs to be implemented that will defer deletion until the process exits. So it is not solved yet. But at least you now have a work-around: manually delete temporary em* files from your TEMP directory. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 05 20:58:32 2012 Received: (at 13079) by debbugs.gnu.org; 6 Dec 2012 01:58:32 +0000 Received: from localhost ([127.0.0.1]:55526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgQjQ-0003XL-4e for submit@debbugs.gnu.org; Wed, 05 Dec 2012 20:58:32 -0500 Received: from mail-lb0-f172.google.com ([209.85.217.172]:43658) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgQjO-0003XC-N3 for 13079@debbugs.gnu.org; Wed, 05 Dec 2012 20:58:31 -0500 Received: by mail-lb0-f172.google.com with SMTP id y2so5280644lbk.3 for <13079@debbugs.gnu.org>; Wed, 05 Dec 2012 17:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kMUSki7tsOCPRiA/uWGbn0qcsMVOQZ4cOHsMXv9IAeg=; b=y3d8n5wPdlRDzDMH5wGDs+5c3e69yCg7G2uYna9ubyQmBuOrNn6hz8VVtwW+lRMJ7L IwTL/a7x8DV30KlR0oMgwEMYXgPI8UA7AuynmtTU42z6cFtkHi78hQ8IlqSw0OB8Hw6f Xz8JMxynYIevPRicf+Evnb/Wqbtu2DkwJdwF2xlWvIA3y5t/V6CDe41chf528tj0T+x+ HtwTVj8B7RW04f6NAn+f4SiVbvFvTZha3/E1LjXkq2xIw/Q8/hK0RcatINRlC6GAPrk6 RH8w/YZ/ou7/ccmimvuzkey7/xPtXvfsdfjFTnMfYk2vyhaqhXYOSce7X8FmBml8bKax 3l5A== MIME-Version: 1.0 Received: by 10.152.110.229 with SMTP id id5mr18668698lab.36.1354759099156; Wed, 05 Dec 2012 17:58:19 -0800 (PST) Received: by 10.114.22.167 with HTTP; Wed, 5 Dec 2012 17:58:19 -0800 (PST) In-Reply-To: <83wqwwpfu1.fsf@gnu.org> References: <83ehj5r2gs.fsf@gnu.org> <83wqwwpfu1.fsf@gnu.org> Date: Thu, 6 Dec 2012 09:58:19 +0800 Message-ID: Subject: Re: bug#13079: 24.3.50; Emacs cannot create subprocess From: Li Zhai To: Eli Zaretskii Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13079 Cc: 13079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) I got it. The maximize number of calling mktemp is 42 if we don't remove the temporary em* files. I found a very interesting discuss about the limit of mktemp on windows. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47439 They implement a new mktemp function to walk around the limit on the number of concurrently open files. Can we implement our mktemp functions instead of using microsoft's stuff? From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 05 22:54:39 2012 Received: (at 13079) by debbugs.gnu.org; 6 Dec 2012 03:54:39 +0000 Received: from localhost ([127.0.0.1]:55628 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgSXn-0007Hg-I1 for submit@debbugs.gnu.org; Wed, 05 Dec 2012 22:54:39 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:36636) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgSXl-0007HU-Qt for 13079@debbugs.gnu.org; Wed, 05 Dec 2012 22:54:38 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MEL00E00C21DI00@a-mtaout23.012.net.il> for 13079@debbugs.gnu.org; Thu, 06 Dec 2012 05:54:25 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MEL00EAWC6P5WB0@a-mtaout23.012.net.il>; Thu, 06 Dec 2012 05:54:25 +0200 (IST) Date: Thu, 06 Dec 2012 05:54:28 +0200 From: Eli Zaretskii Subject: Re: bug#13079: 24.3.50; Emacs cannot create subprocess In-reply-to: X-012-Sender: halo1@inter.net.il To: Li Zhai Message-id: <83obi7q1hn.fsf@gnu.org> References: <83ehj5r2gs.fsf@gnu.org> <83wqwwpfu1.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Thu, 6 Dec 2012 09:58:19 +0800 > From: Li Zhai > Cc: 13079@debbugs.gnu.org > > I got it. The maximize number of calling mktemp is 42 if we don't > remove the temporary em* files. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 13079 Cc: 13079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Thu, 6 Dec 2012 09:58:19 +0800 > From: Li Zhai > Cc: 13079@debbugs.gnu.org > > I got it. The maximize number of calling mktemp is 42 if we don't > remove the temporary em* files. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4955] > Date: Thu, 6 Dec 2012 09:58:19 +0800 > From: Li Zhai > Cc: 13079@debbugs.gnu.org > > I got it. The maximize number of calling mktemp is 42 if we don't > remove the temporary em* files. Yes. > I found a very interesting discuss about the limit of mktemp on windows. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47439 > > They implement a new mktemp function to walk around the limit on the > number of concurrently open files. > > Can we implement our mktemp functions instead of using microsoft's stuff? But that will just push the limit farther. It will not fix the underlying fundamental problem of not deleting temporary files in this case. Since Emacs is typically run for long periods of time, sooner or later the problem will strike anyway. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 06 03:18:27 2012 Received: (at 13079) by debbugs.gnu.org; 6 Dec 2012 08:18:27 +0000 Received: from localhost ([127.0.0.1]:55831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgWf4-0007FB-Ff for submit@debbugs.gnu.org; Thu, 06 Dec 2012 03:18:26 -0500 Received: from mail-la0-f44.google.com ([209.85.215.44]:32803) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgWf1-0007F3-IK for 13079@debbugs.gnu.org; Thu, 06 Dec 2012 03:18:24 -0500 Received: by mail-la0-f44.google.com with SMTP id d3so5317835lah.3 for <13079@debbugs.gnu.org>; Thu, 06 Dec 2012 00:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nMsMmbw3YsLZsQRJvjkif6H5gSht85j/XnfZkfWPui4=; b=WMUJ5AJjsZGryPgRy23QKOJSMQsAlYlL9QljRDSAu3XQHRY/bcDypC3sQo/iyhqhL9 HwGVOVD1IjHddV9geddBAakwnIYYXgxwzi+P7Y3PvvD5NVb5xskha6kjboyKa47nV8GA TQlN2mpZD0lyrASVCc8Fz/m1lFmygTQ2d9PWmyb9agBYBy0+6ZbNmJ31pFT+fK8VBl7c D6kdR7Txm3iPp2d6eqihxmWoIvKA69E/lmBrR7KSHJZAVMEfbShP//Sg7FxnosZwcHk0 97sr+jP5Z6sPhJTtfwRyyu1yG1RpXL51QvuPz8RfWbMWZ5mkGYxFUG2b/Bc0EFFGWMny 0+0Q== MIME-Version: 1.0 Received: by 10.152.110.229 with SMTP id id5mr732600lab.36.1354781890613; Thu, 06 Dec 2012 00:18:10 -0800 (PST) Received: by 10.114.22.167 with HTTP; Thu, 6 Dec 2012 00:18:10 -0800 (PST) In-Reply-To: <83obi7q1hn.fsf@gnu.org> References: <83ehj5r2gs.fsf@gnu.org> <83wqwwpfu1.fsf@gnu.org> <83obi7q1hn.fsf@gnu.org> Date: Thu, 6 Dec 2012 16:18:10 +0800 Message-ID: Subject: Re: bug#13079: 24.3.50; Emacs cannot create subprocess From: Li Zhai To: Eli Zaretskii Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 13079 Cc: 13079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) I've tried another method, using the flag FILE_FLAG_DELETE_ON_CLOSE while open the files. Create a file by passed the flag FILE_FLAG_DELETE_ON_CLOSE to CreateFile, if all the handles are closed, the file will be deleted automatically. I wrote a very simple program to test that feature. It seems works. #include #include #include #include #include #include void main( void ) { HANDLE fh1, fh2; char buf[100]; DWORD dwReadSize; DWORD dwWriteSize; fh1 = CreateFile("temp.txt", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_DELETE_ON_CLOSE, NULL); WriteFile(fh1, "hello", 5, &dwWriteSize, NULL); fh2 = CreateFile("temp.txt", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if (fh2 == INVALID_HANDLE_VALUE) perror( "Open failed on fh2" ); printf("Close the first file handle...\n"); CloseHandle(fh1); printf("Read file...\n"); ReadFile(fh2, buf, 5, &dwReadSize, NULL); buf[5] = 0; printf("File content:\n %s\n", buf); _getch(); printf("Close the second file handle...The file should be deleted\n"); CloseHandle(fh2); } But this method has some limit. Firstly, all the files must create/open by Win32 API, the codes are totally unportable. Secondly, the file must be opened with a flag FILE_SHARE_DELETE, or the file will not be deleted. And I don't know how to integrate the Win32 API with the emacs codes. Emacs codes use POSIX functions(_open, _close, _read...), and the delete_on_close feature required WIN32 API. I've tried using _O_TEMPORARY flags with _open function, but not succeeded. On Thu, Dec 6, 2012 at 11:54 AM, Eli Zaretskii wrote: >> Date: Thu, 6 Dec 2012 09:58:19 +0800 >> From: Li Zhai >> Cc: 13079@debbugs.gnu.org >> >> I got it. The maximize number of calling mktemp is 42 if we don't >> remove the temporary em* files. > > Yes. > >> I found a very interesting discuss about the limit of mktemp on windows. >> >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47439 >> >> They implement a new mktemp function to walk around the limit on the >> number of concurrently open files. >> >> Can we implement our mktemp functions instead of using microsoft's stuff? > > But that will just push the limit farther. It will not fix the > underlying fundamental problem of not deleting temporary files in this > case. Since Emacs is typically run for long periods of time, sooner > or later the problem will strike anyway. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 06 14:05:09 2012 Received: (at 13079) by debbugs.gnu.org; 6 Dec 2012 19:05:09 +0000 Received: from localhost ([127.0.0.1]:57184 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tggkv-0006Yl-3y for submit@debbugs.gnu.org; Thu, 06 Dec 2012 14:05:09 -0500 Received: from mtaout21.012.net.il ([80.179.55.169]:36585) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tggks-0006YX-Cn for 13079@debbugs.gnu.org; Thu, 06 Dec 2012 14:05:07 -0500 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MEM00K00I5ER200@a-mtaout21.012.net.il> for 13079@debbugs.gnu.org; Thu, 06 Dec 2012 21:04:50 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MEM00KEVIC1R010@a-mtaout21.012.net.il>; Thu, 06 Dec 2012 21:04:50 +0200 (IST) Date: Thu, 06 Dec 2012 21:04:54 +0200 From: Eli Zaretskii Subject: Re: bug#13079: 24.3.50; Emacs cannot create subprocess In-reply-to: X-012-Sender: halo1@inter.net.il To: Li Zhai Message-id: <83boe7ovc9.fsf@gnu.org> References: <83ehj5r2gs.fsf@gnu.org> <83wqwwpfu1.fsf@gnu.org> <83obi7q1hn.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Thu, 6 Dec 2012 16:18:10 +0800 > From: Li Zhai > Cc: 13079@debbugs.gnu.org > > I've tried another method, using the flag FILE_FLAG_DELETE_ON_CLOSE > while open the files. > > Create a file by passed the flag FILE_FLAG_DELETE_ON_CLOSE to > CreateFile, if all the handles are closed, the file will be deleted > automatically. I wrote a very simple program to test that feature. It > seems works. > > #include > #include > #include > #include > #include > #include > > void main( void ) > { > HANDLE fh1, fh2; > char buf[100]; > DWORD dwReadSize; > DWORD dwWriteSize; > > fh1 = CreateFile("temp.txt", GENERIC_READ | GENERIC_WRITE, > FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, > NULL, CREATE_ALWAYS, > FILE_ATTRIBUTE_NORMAL | FILE_FLAG_DELETE_ON_CLOSE, NULL); > > WriteFile(fh1, "hello", 5, &dwWriteSize, NULL); > > fh2 = CreateFile("temp.txt", GENERIC_READ | GENERIC_WRITE, > FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, > NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > if (fh2 == INVALID_HANDLE_VALUE) > perror( "Open failed on fh2" ); > > printf("Close the first file handle...\n"); > CloseHandle(fh1); > > printf("Read file...\n"); > ReadFile(fh2, buf, 5, &dwReadSize, NULL); > buf[5] = 0; > printf("File content:\n %s\n", buf); > > _getch(); > > printf("Close the second file handle...The file should be deleted\n"); > CloseHandle(fh2); > } > > > But this method has some limit. Firstly, all the files must > create/open by Win32 API, the codes are totally unportable. Secondly, > the file must be opened with a flag FILE_SHARE_DELETE, or the file > will not be deleted. > > And I don't know how to integrate the Win32 API with the emacs codes. > Emacs codes use POSIX functions(_open, _close, _read...), and the > delete_on_close feature required WIN32 API. I've tried using > _O_TEMPORARY flags with _open function, but not succeeded. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.169 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4844] X-Debbugs-Envelope-To: 13079 Cc: 13079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) > Date: Thu, 6 Dec 2012 16:18:10 +0800 > From: Li Zhai > Cc: 13079@debbugs.gnu.org > > I've tried another method, using the flag FILE_FLAG_DELETE_ON_CLOSE > while open the files. > > Create a file by passed the flag FILE_FLAG_DELETE_ON_CLOSE to > CreateFile, if all the handles are closed, the file will be deleted > automatically. I wrote a very simple program to test that feature. It > seems works. > > #include > #include > #include > #include > #include > #include > > void main( void ) > { > HANDLE fh1, fh2; > char buf[100]; > DWORD dwReadSize; > DWORD dwWriteSize; > > fh1 = CreateFile("temp.txt", GENERIC_READ | GENERIC_WRITE, > FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, > NULL, CREATE_ALWAYS, > FILE_ATTRIBUTE_NORMAL | FILE_FLAG_DELETE_ON_CLOSE, NULL); > > WriteFile(fh1, "hello", 5, &dwWriteSize, NULL); > > fh2 = CreateFile("temp.txt", GENERIC_READ | GENERIC_WRITE, > FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, > NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > > if (fh2 == INVALID_HANDLE_VALUE) > perror( "Open failed on fh2" ); > > printf("Close the first file handle...\n"); > CloseHandle(fh1); > > printf("Read file...\n"); > ReadFile(fh2, buf, 5, &dwReadSize, NULL); > buf[5] = 0; > printf("File content:\n %s\n", buf); > > _getch(); > > printf("Close the second file handle...The file should be deleted\n"); > CloseHandle(fh2); > } > > > But this method has some limit. Firstly, all the files must > create/open by Win32 API, the codes are totally unportable. Secondly, > the file must be opened with a flag FILE_SHARE_DELETE, or the file > will not be deleted. > > And I don't know how to integrate the Win32 API with the emacs codes. > Emacs codes use POSIX functions(_open, _close, _read...), and the > delete_on_close feature required WIN32 API. I've tried using > _O_TEMPORARY flags with _open function, but not succeeded. Yes, this technique will not help, for all the reasons you mention, and then some. For starters, in our case the problem is not with Emacs holding the file open -- the call to write-region within call-process-region closes the file before it returns -- but with the child process that has the file connected to its standard input. So another process is involved here, not just Emacs. Also, Emacs always uses emacs_open to open any files, which means it doesn't know which files are temporary and which aren't. Obviously, we cannot open all files with FILE_FLAG_DELETE_ON_CLOSE or _O_TEMPORARY, because most files Emacs writes should _not_ be deleted when Emacs closes them. Anyway, I think the solution to this should be to somehow retry the deletion later, when the child process exits. Nothing else will resolve this bug. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 15 08:42:56 2012 Received: (at 13079-done) by debbugs.gnu.org; 15 Dec 2012 13:42:56 +0000 Received: from localhost ([127.0.0.1]:43494 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tjs11-00058T-RC for submit@debbugs.gnu.org; Sat, 15 Dec 2012 08:42:56 -0500 Received: from mtaout20.012.net.il ([80.179.55.166]:50237) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tjs0x-00058I-VZ for 13079-done@debbugs.gnu.org; Sat, 15 Dec 2012 08:42:53 -0500 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MF200900RC5GX00@a-mtaout20.012.net.il> for 13079-done@debbugs.gnu.org; Sat, 15 Dec 2012 15:41:36 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MF2009XQRDC2NA0@a-mtaout20.012.net.il>; Sat, 15 Dec 2012 15:41:36 +0200 (IST) Date: Sat, 15 Dec 2012 15:41:41 +0200 From: Eli Zaretskii Subject: Re: bug#13079: 24.3.50; Emacs cannot create subprocess In-reply-to: <83wqwwpfu1.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: mrzhaili@gmail.com Message-id: <83fw37mnze.fsf@gnu.org> References: <83ehj5r2gs.fsf@gnu.org> <83wqwwpfu1.fsf@gnu.org> X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Wed, 05 Dec 2012 19:29:58 +0200 > From: Eli Zaretskii > Cc: 13079@debbugs.gnu.org > > The harder part of this bug is the reason _why_ 'mktemp' fails. Your > command launches asynchronous subprocesses, creating a temporary file > for each one of them where Emacs puts the contents of the region. In > this case, call-process-region arranges for the temporary files to be > removed when the call to call-process returns, and then calls > call-process. However, since this is an async subprocess, > call-process returns immediately, without waiting for the subprocess > to exit, and Emacs deletes the temporary file. This "cleanup" uses > the non-portable (outside of Posix filesystems) trick of deleting a > file while it is still open and used by the child process. On > Windows, this attempt to delete the file fails, and the file is left > behind. > > The other part of this puzzle is that 'mktemp' as implemented by the > Windows runtime can only have up to 42 simultaneous temporary files > per calling thread (the MSDN documentation says 26, but that's a lie). > Once there are 42 files in your TEMP directory created by a single > Emacs session, all the future calls to 'mktemp' from the same session > will fail, unless you manually delete those files. > > This part of the bug is harder to solve, because some code needs to be > implemented that will defer deletion until the process exits. So it > is not solved yet. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 13079-done Cc: 13079-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Wed, 05 Dec 2012 19:29:58 +0200 > From: Eli Zaretskii > Cc: 13079@debbugs.gnu.org > > The harder part of this bug is the reason _why_ 'mktemp' fails. Your > command launches asynchronous subprocesses, creating a temporary file > for each one of them where Emacs puts the contents of the region. In > this case, call-process-region arranges for the temporary files to be > removed when the call to call-process returns, and then calls > call-process. However, since this is an async subprocess, > call-process returns immediately, without waiting for the subprocess > to exit, and Emacs deletes the temporary file. This "cleanup" uses > the non-portable (outside of Posix filesystems) trick of deleting a > file while it is still open and used by the child process. On > Windows, this attempt to delete the file fails, and the file is left > behind. > > The other part of this puzzle is that 'mktemp' as implemented by the > Windows runtime can only have up to 42 simultaneous temporary files > per calling thread (the MSDN documentation says 26, but that's a lie). > Once there are 42 files in your TEMP directory created by a single > Emacs session, all the future calls to 'mktemp' from the same session > will fail, unless you manually delete those files. > > This part of the bug is harder to solve, because some code needs to be > implemented that will defer deletion until the process exits. So it > is not solved yet. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.166 listed in list.dnswl.org] 0.0 SINGLE_HEADER_2K A single header contains 2K-3K characters 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4991] > Date: Wed, 05 Dec 2012 19:29:58 +0200 > From: Eli Zaretskii > Cc: 13079@debbugs.gnu.org > > The harder part of this bug is the reason _why_ 'mktemp' fails. Your > command launches asynchronous subprocesses, creating a temporary file > for each one of them where Emacs puts the contents of the region. In > this case, call-process-region arranges for the temporary files to be > removed when the call to call-process returns, and then calls > call-process. However, since this is an async subprocess, > call-process returns immediately, without waiting for the subprocess > to exit, and Emacs deletes the temporary file. This "cleanup" uses > the non-portable (outside of Posix filesystems) trick of deleting a > file while it is still open and used by the child process. On > Windows, this attempt to delete the file fails, and the file is left > behind. > > The other part of this puzzle is that 'mktemp' as implemented by the > Windows runtime can only have up to 42 simultaneous temporary files > per calling thread (the MSDN documentation says 26, but that's a lie). > Once there are 42 files in your TEMP directory created by a single > Emacs session, all the future calls to 'mktemp' from the same session > will fail, unless you manually delete those files. > > This part of the bug is harder to solve, because some code needs to be > implemented that will defer deletion until the process exits. So it > is not solved yet. Should be fixed now (revision 11244 on the trunk). I was able to run your test case multiple times without any errors, and after that, there were no left-over temporary files in the temporary directory. From unknown Mon Aug 18 00:08:19 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 13 Jan 2013 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator