From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/68272 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.gnus.general Subject: Re: (file-error "writing to process" "bad address" #) when Gcc-ing a group Date: Tue, 10 Feb 2009 14:51:14 +0100 Message-ID: References: <873aenr2gk.fsf@thinkpad.tsdh.de> <87tz73plyd.fsf@thinkpad.tsdh.de> <87ab8v7651.fsf@thinkpad.tsdh.de> <87y6wf43fr.fsf@randomsample.de> <87fxim8wi9.fsf@thinkpad.tsdh.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1234273958 1363 80.91.229.12 (10 Feb 2009 13:52:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Feb 2009 13:52:38 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M16712@lists.math.uh.edu Tue Feb 10 14:53:53 2009 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1LWt3f-0004Yf-Me for ding-account@gmane.org; Tue, 10 Feb 2009 14:53:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1LWt1M-0001qq-Aj; Tue, 10 Feb 2009 07:51:28 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1LWt1K-0001qY-Ot for ding@lists.math.uh.edu; Tue, 10 Feb 2009 07:51:26 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.69) (envelope-from ) id 1LWt1H-0003GZ-Lo for ding@lists.math.uh.edu; Tue, 10 Feb 2009 07:51:26 -0600 Original-Received: from m61s02.vlinux.de ([83.151.21.164]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1LWt1b-00087o-00 for ; Tue, 10 Feb 2009 14:51:43 +0100 Original-Received: from [134.76.4.218] (helo=Macintosh.local) by m61s02.vlinux.de with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1LWt2n-0007LI-5O for ding@gnus.org; Tue, 10 Feb 2009 14:52:57 +0100 In-Reply-To: (David Engster's message of "Tue, 10 Feb 2009 11:02:54 +0100") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (darwin) Mail-Copies-To: never Mail-Followup-To: ding@gnus.org X-Spam-Score: -2.6 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:68272 Archived-At: David Engster writes: > Tassilo Horn writes: >> David Engster writes: >>> I have no idea if this is a problem with Dovecot or maybe a bug in >>> process-send-region or in send-region (I don't see how any other Gnus >>> or Emacs code could be involved in this). >> >> `send-region' is only an alias for `process-send-region'. > > Sorry, I should have said "send-region in process.c". The file-error is > thrown there, in the C source. Make that "send_process"... >> Maybe we could create an isolated test case which doesn't involve gnus >> and dovecot. I tried to create such a case, but I don't have enough >> time right now. Basically it should be possible to load a big file >> into a temp buffer and use it as input to a `cat' process, or >> something like that and then compare if the result equals the input. > > I'd be surprised if the error is that general; much more people would > have to see it in this case. Well, color me surprised. I was just able to provoke the error with the procedure you suggested: (setq numlines 500000) (progn (setq proctest (start-process "cat" (get-buffer-create "cat") "/bin/cat")) (with-temp-buffer (dotimes (dummy numlines) (insert (concat (number-to-string (random)) (number-to-string (random)) (number-to-string (random)) (number-to-string (random)) "\n"))) (process-send-region proctest (point-min) (point-max))) (delete-process proctest)) And sometimes(!) I get: Debugger entered--Lisp error: (file-error "writing to process" "bad address" #) process-send-region(# 1 18672117) using Emacs from CVS (2009-02-04) on Darwin/Mac OS X. The error doesn't always happen. I usually have to repeat the procedure several times until it occurs. You can increase 'numlines' to make it more likely. It might also be that it depends on the load of the system or something like that. Maybe this http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=471 might also be connected to this issue. -David