From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: don@donarmstrong.com (Emacs bug Tracking System) Newsgroups: gmane.emacs.bugs Subject: bug#844: marked as done (23.0.60; ediff-merge-revision: Buffer exceeds maximum size) Date: Tue, 2 Sep 2008 17:25:06 -0700 Message-ID: References: <871w026pyo.fsf@cyd.mit.edu> <20080831184354.0dafde58@kiferserv> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_1220401506-1618-0" X-Trace: ger.gmane.org 1220401727 17595 80.91.229.12 (3 Sep 2008 00:28:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Sep 2008 00:28:47 +0000 (UTC) To: Chong Yidong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 03 02:29:42 2008 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KagFh-0003EW-8j for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Sep 2008 02:29:41 +0200 Original-Received: from localhost ([127.0.0.1]:50661 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KagEh-00042n-V0 for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Sep 2008 20:28:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KagDj-0003DT-UD for bug-gnu-emacs@gnu.org; Tue, 02 Sep 2008 20:27:39 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KagDf-0003B7-UR for bug-gnu-emacs@gnu.org; Tue, 02 Sep 2008 20:27:37 -0400 Original-Received: from [199.232.76.173] (port=48154 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KagDf-0003AL-7a for bug-gnu-emacs@gnu.org; Tue, 02 Sep 2008 20:27:35 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:56520) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KagDe-0001s9-Ar for bug-gnu-emacs@gnu.org; Tue, 02 Sep 2008 20:27:34 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m830RU7h002893; Tue, 2 Sep 2008 17:27:32 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m830P6JE001666; Tue, 2 Sep 2008 17:25:06 -0700 X-Mailer: MIME-tools 5.420 (Entity 5.420) X-Loop: don@donarmstrong.com X-Emacs-PR-Message: closed 844 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: unreproducible X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:20068 Archived-At: This is a multi-part message in MIME format... ------------=_1220401506-1618-0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Your message dated Tue, 02 Sep 2008 20:19:27 -0400 with message-id <871w026pyo.fsf@cyd.mit.edu> and subject line Re: 23.0.60; ediff-merge-revision: Buffer exceeds maximum = size has caused the Emacs bug report #844, regarding 23.0.60; ediff-merge-revision: Buffer exceeds maximum size to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don@donarmstrong.com immediately.) --=20 844: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3D844 Emacs Bug Tracking System Contact don@donarmstrong.com with problems ------------=_1220401506-1618-0 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-5.7 required=4.0 tests=AWL,BAYES_00,FOURLA,GMAIL, MURPHY_DRUGS_REL8,RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 31 Aug 2008 22:44:05 +0000 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m7VMi1ld011484 for ; Sun, 31 Aug 2008 15:44:02 -0700 Received: from mx10.gnu.org ([199.232.76.166]:43449) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1KZvco-00005E-Di for emacs-pretest-bug@gnu.org; Sun, 31 Aug 2008 18:42:26 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1KZveH-0000Rb-4b for emacs-pretest-bug@gnu.org; Sun, 31 Aug 2008 18:44:00 -0400 Received: from sbcs.sunysb.edu ([130.245.1.15]:53842 helo=sbcs.cs.sunysb.edu) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KZveG-0000RT-Ox for emacs-pretest-bug@gnu.org; Sun, 31 Aug 2008 18:43:56 -0400 Received: from kiferserv (compserv1 [130.245.1.44]) by sbcs.cs.sunysb.edu (8.13.6/8.12.11) with ESMTP id m7VMhrRQ026172; Sun, 31 Aug 2008 18:43:54 -0400 (EDT) Date: Sun, 31 Aug 2008 18:43:54 -0400 From: Michael Kifer To: "Lennart Borgman (gmail)" Cc: emacs-pretest-bug@gnu.org Subject: Re: 23.0.60; ediff-merge-revision: Buffer exceeds maximum size Message-ID: <20080831184354.0dafde58@kiferserv> In-Reply-To: <48BB0FBD.4040209@gmail.com> References: <48BA9F45.2090908@gmail.com> <20080831153637.1103334a@kiferserv> <48BB0FBD.4040209@gmail.com> Reply-To: kifer@cs.sunysb.edu Organization: Stony Brook University X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.9; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-detected-kernel: by monty-python.gnu.org: Solaris 10 (1203?) On Sun, 31 Aug 2008 23:40:13 +0200 "Lennart Borgman (gmail)" wrote: > Michael Kifer wrote: > > > > On Sun, 31 Aug 2008 15:40:21 +0200 > > "Lennart Borgman (gmail)" wrote: > > > >> When I just made a checkout of Emacs from CVS I got a merge conflict > >> which I used ediff-revision to resolve. I then got the following back > >> trace when I did "wb" to save the corrected file: > >> > >> Debugger entered--Lisp error: (error "Buffer exceeds maximum size") > >> call-process("diff" nil # nil "-c" > > > > This says that the output of diff -c exceeds the buffer size. > > > > It is unclear how this is related to ediff per se, since ediff merely calls > > call-process with the above command. > > > >> "c:/DOCUME~1/LENNAR~1/LOCALS~1/Temp/ediff282470M" > >> "c:/ecvsnew/bld/emacs/src/w32term.c") > >> apply(call-process "diff" nil # nil ("-c" > >> "c:/DOCUME~1/LENNAR~1/LOCALS~1/Temp/ediff282470M" > >> "c:/ecvsnew/bld/emacs/src/w32term.c")) > >> ediff-exec-process("diff" # synchronize > >> "-c" "c:/DOCUME~1/LENNAR~1/LOCALS~1/Temp/ediff282470M" > >> "c:/ecvsnew/bld/emacs/src/w32term.c") > >> ediff-compute-custom-diffs-maybe() > >> ediff-save-buffer(nil) > >> call-interactively(ediff-save-buffer nil nil) > >> > >> Looking into ediff-custom-diff I can see there is some problem with ^M: > > > > Can you explain what the problem is? It is unclear from the included text below. > > Sorry, I thought the part of the output below should show it, but of > course the ^M characters I saw is gone here... > > Lines somewhere below the middle of the output below had extra ^M at the > end of them. > > I can't reproduce the problem now, maybe it was some kind of temporary > problem - perhaps a bad checkin to the CVS at that time? I don't know -haven't seen this. But the main problem seems to have been that diff -c produced a very large buffer, although I can't imagine how big it could have been in order to cause the "Buffer exceeds maximum size" error. In any case, it seems to be a problem with diff or call-process, if at all. > > In any case, I deed to be able to reproduce it in order to be able to determine > > if something needs to be fixed in ediff. Right now it does not look like > > an ediff problem. > > > > michael > > > > > >> ! emacs_event->part = scroll_bar_handle; > >> ! y = 0; > >> ! break; > >> case SB_BOTTOM: > >> ! emacs_event->part = scroll_bar_handle; > >> ! y = top_range; > >> ! break; > >> case SB_THUMBTRACK: > >> case SB_THUMBPOSITION: > >> ! if (VERTICAL_SCROLL_BAR_TOP_RANGE (f, XINT (bar->height)) <= 0xffff) > >> y = HIWORD (msg->msg.wParam); > >> > >> ! bar->dragging = Qt; > >> > >> ! emacs_event->part = scroll_bar_handle; > >> > >> > >> > >> ! /* "Silently" update current position. */ > >> > >> ! { > >> > >> ! SCROLLINFO si; > >> > >> > >> > >> > >> This was with my patched version, but I do not think I have any patches > >> that comes in here: > >> > >> In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) > >> of 2008-08-28 (patched) > >> Windowing system distributor `Microsoft Corp.', version 5.1.2600 > >> configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' > >> > >> > > > ------------=_1220401506-1618-0 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-3.8 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 844-done) by emacsbugs.donarmstrong.com; 3 Sep 2008 00:17:07 +0000 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m830H4a0031913 for <844-done@emacsbugs.donarmstrong.com>; Tue, 2 Sep 2008 17:17:06 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id 80D5257E339; Tue, 2 Sep 2008 20:19:27 -0400 (EDT) To: "Lennart Borgman \(gmail\)" Cc: 844-done@emacsbugs.donarmstrong.com Subject: Re: 23.0.60; ediff-merge-revision: Buffer exceeds maximum size From: Chong Yidong Date: Tue, 02 Sep 2008 20:19:27 -0400 Message-ID: <871w026pyo.fsf@cyd.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Are you able to reproduce this? ------------=_1220401506-1618-0--