From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Crash in handling tar files (Was: GDB debugger mode for Emacs in ELPA) Date: Mon, 30 Jun 2008 22:33:49 +0300 Message-ID: References: <328703.29642.qm@web95004.mail.in2.yahoo.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1214854467 4136 80.91.229.12 (30 Jun 2008 19:34:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Jun 2008 19:34:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: filerz-emacs@yahoo.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 30 21:35:12 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KDP9U-0001hS-5J for ged-emacs-devel@m.gmane.org; Mon, 30 Jun 2008 21:35:04 +0200 Original-Received: from localhost ([127.0.0.1]:54883 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KDP8d-0003Jz-U6 for ged-emacs-devel@m.gmane.org; Mon, 30 Jun 2008 15:34:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KDP8Y-0003Id-OV for emacs-devel@gnu.org; Mon, 30 Jun 2008 15:34:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KDP8V-0003Hd-Jn for emacs-devel@gnu.org; Mon, 30 Jun 2008 15:34:06 -0400 Original-Received: from [199.232.76.173] (port=51838 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KDP8V-0003Ha-E6 for emacs-devel@gnu.org; Mon, 30 Jun 2008 15:34:03 -0400 Original-Received: from mtaout7.012.net.il ([84.95.2.19]:11544) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KDP8U-00010N-UW for emacs-devel@gnu.org; Mon, 30 Jun 2008 15:34:03 -0400 Original-Received: from HOME-C4E4A596F7 ([80.230.31.196]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K3A001ANIWPKF50@i-mtaout7.012.net.il> for emacs-devel@gnu.org; Mon, 30 Jun 2008 22:17:14 +0300 (IDT) In-reply-to: <328703.29642.qm@web95004.mail.in2.yahoo.com> X-012-Sender: halo1@inter.net.il X-detected-kernel: by monty-python.gnu.org: Solaris 10 (1203?) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:100238 Archived-At: > Date: Mon, 30 Jun 2008 09:25:04 +0530 (IST) > From: filerz-emacs@yahoo.com > Cc: emacs-devel@gnu.org > > Do we really need a different allocation method for M$? How do you mean ``different''? REL_ALLOC is used not only on MS-Windows. > Looks like the REL_ALLOC is a pool based allocator. Could someone > comment on benefits seen in using this pool based allocation? REL_ALLOC (actually, ralloc.c) is a relocatable memory allocator. Its benefit is that, unlike most (maybe all?) malloc implementations, it can recover from memory fragmentation by relocating some of the Lisp objects (strings and buffers, IIRC) in order to bring small fragmented chunks of free memory into larger and less scattered ones. Thus, when large memory buffers are requested by alloc.c, ralloc.c can serve those requests for longer time without asking more core from the OS. Without ralloc.c, Emacs's memory footprint tends to grow much faster and does not always level out. You can try it: just recompile Emacs without REL_ALLOC defined, and run it in a long, real-life editing session; then compare the memory footprints. > If this is used only in M$ platform, we could create multiple heaps at startup and use them. Once the heap becomes highly fragmented (we can use the low fragmentation heap), we can create a new heap, wait till all references to the fragmented heap are freed and destroy the fragmented heap. Since Emacs is single threaded, we can create a heap with no serialization, that will further speedup the allocations on M$. Do we really want to develop a new memory allocation scheme from scratch? ralloc.c is used on many platforms for many years (GNU/Linux stopped using it because they use mmap and Doug Lea's allocator (again IIRC), which is even better than ralloc.c). There's no reason to believe ralloc.c causes any real trouble, certainly not because of some petty bug in tar-mode.el or thereabouts! > Even the second scenario (without loading the 'tar-mode') does not happen on GNU/Linux (as REL_ALLOC stuff is not used there I guess) You are assuming that this is ralloc.c's fault. But it's much more probable that it's some memory corruption elsewhere, and if that is the case, other memory allocation mechanisms will see it as well. > I could reproduce by creating a tar file with 'src/w32.c' as "tar cvf crash.tar src/w32.c". Here is the backtrace: > > (gdb) bt > #0 0x0119eaf3 in re_search_2 (bufp=0x1376420, str1=0x388a160 "ostfix modifiers\"\n \"quail/latin-alt\")\n(register-input-method\n \"latin-3-alt-postfix\" \"Latin-3\" 'quail-use-package\n \"3<\" \"Latin-3 char This is strange text! What is your value of auto-coding-regexp-alist? Do you have any idea why auto-coding-regexp-alist-lookup ended up looking at the string pointed to by str1 above?