From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#2790: emacs 22.1.1 cannot open 5GB file on 64GB 64-bit GNU/Linux box Date: Sat, 28 Mar 2009 11:45:35 +0300 Message-ID: References: <3c6c07c20903260850r180e942dscb2c61d1096793f8@mail.gmail.com> <3c6c07c20903270927y5292e32as857233aa1fd75737@mail.gmail.com> Reply-To: Eli Zaretskii , 2790@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1238231087 24988 80.91.229.12 (28 Mar 2009 09:04:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 28 Mar 2009 09:04:47 +0000 (UTC) Cc: tutufan@gmail.com To: Stefan Monnier , 2790@emacsbugs.donarmstrong.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 28 10:06:04 2009 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 1LnUTj-000279-OX for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Mar 2009 10:05:55 +0100 Original-Received: from localhost ([127.0.0.1]:42009 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LnUSM-0007nf-F1 for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 Mar 2009 05:03:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LnUSI-0007na-H9 for bug-gnu-emacs@gnu.org; Sat, 28 Mar 2009 05:03:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LnUSC-0007n4-QR for bug-gnu-emacs@gnu.org; Sat, 28 Mar 2009 05:03:53 -0400 Original-Received: from [199.232.76.173] (port=39889 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LnUSC-0007n1-Lu for bug-gnu-emacs@gnu.org; Sat, 28 Mar 2009 05:03:48 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:54510) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LnUSB-0004cP-SI for bug-gnu-emacs@gnu.org; Sat, 28 Mar 2009 05:03:48 -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 n2S93jVN003590; Sat, 28 Mar 2009 02:03:46 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n2S8t4G6001115; Sat, 28 Mar 2009 01:55:04 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Eli Zaretskii Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 28 Mar 2009 08:55:04 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 2790 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 2790-submit@emacsbugs.donarmstrong.com id=B2790.123823006932127 (code B ref 2790); Sat, 28 Mar 2009 08:55:04 +0000 Original-Received: (at 2790) by emacsbugs.donarmstrong.com; 28 Mar 2009 08:47:49 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from mtaout2.012.net.il (mtaout2.012.net.il [84.95.2.4]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n2S8ljed032120 for <2790@emacsbugs.donarmstrong.com>; Sat, 28 Mar 2009 01:47:46 -0700 Original-Received: from conversion-daemon.i_mtaout2.012.net.il by i_mtaout2.012.net.il (HyperSendmail v2004.12) id <0KH700A00KESGE00@i_mtaout2.012.net.il> for 2790@emacsbugs.donarmstrong.com; Sat, 28 Mar 2009 11:47:39 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.23.114]) by i_mtaout2.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KH700KITKFDJX20@i_mtaout2.012.net.il>; Sat, 28 Mar 2009 11:47:38 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Sat, 28 Mar 2009 05:03:53 -0400 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:26702 Archived-At: > From: Stefan Monnier > Date: Fri, 27 Mar 2009 22:12:54 -0400 > Cc: 2790@emacsbugs.donarmstrong.com > > > Okay, tried it (emacs-23.0.91), but no luck. Looks very nice, but > > finding that large file produced the same error. The value of > > 'most-positive-fixnum' prints correctly, though (which is different). > > There was an incorrect check that limited the size to INT_MAX/4 > (i.e. 512MB for systems where ints are 32bit). I've removed this check > in the CVS code (see patch below). The patch below does this: > - || st.st_size > INT_MAX / 4) > + /* Actually, it should test either INT_MAX or LONG_MAX > + depending on which one is used for EMACS_INT. But in > + any case, in practice, this test is redundant with the > + one above. > + || st.st_size > INT_MAX / 4 */) > error ("Maximum buffer size exceeded"); But what about the commentary immediately preceding the modified code: The calculations below double the file size twice, so check that it can be multiplied by 4 safely. I'm not sure to which calculations it alludes, but if you think they are no longer relevant, please remove that part of the comment, otherwise we will wonder in a couple of years why the code does not do what the comment says it should. Personally, I would change INT_MAX/4 to LONG_MAX/4, because that does TRT on all supported platforms, 32-bit and 64-bit alike (long and int are both 32-bit wide on 32-bit machines). That would avoid too radical changes during a pretest, which is a Good Thing, IMO. > Note also that when you open large files, it's worthwhile to use > find-file-literally to be sure it's opened in unibyte mode; > otherwise it gets decoded which takes ages. Perhaps the prompt we pop for large file should suggest visiting literally as an option. > Also if the file has many lines (my > 800MB file was made up by copying a C file many times, so it had > millions of lines), turning off line-number-mode is is needed to recover > responsiveness when navigating near the end of the buffer. Perhaps we should make the default value of line-number-display-limit non-nil, at least in 64-bit builds.