From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: filerz-emacs@yahoo.com Newsgroups: gmane.emacs.devel Subject: Re: Crash in handling tar files (Was: GDB debugger mode for Emacs in ELPA) Date: Mon, 30 Jun 2008 09:25:04 +0530 (IST) Message-ID: <328703.29642.qm@web95004.mail.in2.yahoo.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1214798124 22652 80.91.229.12 (30 Jun 2008 03:55:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Jun 2008 03:55:24 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 30 05:56:09 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 1KDAUq-0007RB-Kj for ged-emacs-devel@m.gmane.org; Mon, 30 Jun 2008 05:56:08 +0200 Original-Received: from localhost ([127.0.0.1]:44726 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KDAU0-0005kG-9e for ged-emacs-devel@m.gmane.org; Sun, 29 Jun 2008 23:55:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KDATv-0005hg-8Y for emacs-devel@gnu.org; Sun, 29 Jun 2008 23:55:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KDATt-0005f1-8j for emacs-devel@gnu.org; Sun, 29 Jun 2008 23:55:09 -0400 Original-Received: from [199.232.76.173] (port=45072 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KDATt-0005ek-3M for emacs-devel@gnu.org; Sun, 29 Jun 2008 23:55:09 -0400 Original-Received: from n7a.bullet.tw1.yahoo.com ([119.160.244.194]:41120) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KDATs-0006Ki-66 for emacs-devel@gnu.org; Sun, 29 Jun 2008 23:55:09 -0400 Original-Received: from [119.160.244.77] by n7.bullet.tw1.yahoo.com with NNFMP; 30 Jun 2008 03:55:05 -0000 Original-Received: from [202.43.196.225] by t2.bullet.tw1.yahoo.com with NNFMP; 30 Jun 2008 03:55:05 -0000 Original-Received: from [203.212.168.61] by t2.bullet.tpe.yahoo.com with NNFMP; 30 Jun 2008 03:55:05 -0000 Original-Received: from [203.104.18.55] by t2.bullet.kr1.yahoo.com with NNFMP; 30 Jun 2008 03:55:04 -0000 Original-Received: from [127.0.0.1] by omp107.mail.in2.yahoo.com with NNFMP; 30 Jun 2008 03:55:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 519613.94206.bm@omp107.mail.in2.yahoo.com Original-Received: (qmail 30067 invoked by uid 60001); 30 Jun 2008 03:55:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=sBuD7Qqkmx4DGGg1RSmWpzkxE3yD0J9IEZcblU3o9/eNTOuWxcGZIfMiiG5xturKKMTpMFnH2XSoTLvRx0a3QI/EN/k9sOl61kFdTXZPDqpht2nUfinAUTR9i5voitq9d56ZxLGQC0IxNVgbJC3U5m9c6fS+9V6wkxtWqDCeUw4=; Original-Received: from [202.3.112.9] by web95004.mail.in2.yahoo.com via HTTP; Mon, 30 Jun 2008 09:25:04 IST X-Mailer: YahooMailRC/975.49 YahooMailWebService/0.7.199 X-detected-kernel: by monty-python.gnu.org: FreeBSD 6.x (1) 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:100185 Archived-At: Hello,=0A Do we really need a different allocation method for M$? Looks lik= e the REL_ALLOC is a pool based allocator. Could someone comment on benefit= s seen in using this pool based allocation? If this is used only in M$ plat= form, 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 free= d and destroy the fragmented heap. Since Emacs is single threaded, we can c= reate a heap with no serialization, that will further speedup the allocatio= ns on M$.=0A=0AIf someone confirms that REL_ALLOC is primarily for M$ or fe= el it might be worth exploring the above, I am willing to give it a try (as= I have done that in my day job).=0A=0A----- Original Message ----=0A> From= : Eli Zaretskii =0A> =0A> Does anyone see this problem on pla= tforms other than MS-Windows?=0A=0AI do not see it on GNU/Linux platform.= =0A =0A> > I saw another crash with the following steps:=0A> > 1. Repeat #1= , #2 from the previous scenario=0A> > 2. Open the tar file, you will see th= e file listing=0A> > 3. Position the cursor on one of the listed files and = hit enter (open the file =0A> in the archive)=0A> > You see a crash. Stack = trace follows for 2nd scenario:=0A> =0A> It doesn't crash for me with these= steps. Maybe here the exact=0A> contents of the tarball does matter, at l= east the file names in it=0A> (look at the Lisp backtrace).=0A=0AEven the s= econd scenario (without loading the 'tar-mode') does not happen on GNU/Linu= x (as REL_ALLOC stuff is not used there I guess)=0A=0AI could reproduce by = creating a tar file with 'src/w32.c' as "tar cvf crash.tar src/w32.c". Here= is the backtrace:=0A=0A(gdb) bt=0A#0 0x0119eaf3 in re_search_2 (bufp=3D0x= 1376420, str1=3D0x388a160 "ostfix modifiers\"\n \"quail/latin-alt\")\n(regi= ster-input-method\n \"latin-3-alt-postfix\" \"Latin-3\" 'quail-use-package\= n \"3<\" \"Latin-3 char=0A#1 0x0114fb2f in search_buffer (string=3D4420568= 3, pos=3D513, pos_byte=3D513, lim=3D127920, lim_byte=3D127920, n=3D1, RE=3D= 1, trt=3D53274628, inverse_trt=3D53274116, posix=3D0) at search.c:1190=0A#2= 0x0114f495 in search_command (string=3D44205683, bound=3D1023360, noerror= =3D43722801, count=3D43722753, direction=3D1, RE=3D1, posix=3D0) at search.= c:972=0A#3 0x011533c2 in Fre_search_forward (regexp=3D44205683, bound=3D10= 23360, noerror=3D43722801, count=3D43722753) at search.c:2306=0A#4 0x01023= f1a in Ffuncall (nargs=3D4, args=3D0x82ebf0) at eval.c:3052=0A#5 0x011171e= e in Fbyte_code (bytestr=3D18836419, vector=3D18836436, maxdepth=3D32) at b= ytecode.c:678=0A#6 0x010245fb in funcall_lambda (fun=3D18836372, nargs=3D2= , arg_vector=3D0x82ef04) at eval.c:3229=0A#7 0x010240cf in Ffuncall (nargs= =3D3, args=3D0x82ef00) at eval.c:3088=0A#8 0x011171ee in Fbyte_code (bytes= tr=3D18837043, vector=3D18837060, maxdepth=3D48) at bytecode.c:678=0A#9 0x= 010245fb in funcall_lambda (fun=3D18836996, nargs=3D2, arg_vector=3D0x82f22= 4) at eval.c:3229=0A#10 0x010240cf in Ffuncall (nargs=3D3, args=3D0x82f220)= at eval.c:3088=0A#11 0x011171ee in Fbyte_code (bytestr=3D18837715, vector= =3D18837732, maxdepth=3D32) at bytecode.c:678=0A#12 0x010245fb in funcall_l= ambda (fun=3D18837668, nargs=3D2, arg_vector=3D0x82f534) at eval.c:3229=0A#= 13 0x010240cf in Ffuncall (nargs=3D3, args=3D0x82f530) at eval.c:3088=0A#14= 0x011171ee in Fbyte_code (bytestr=3D53331011, vector=3D45840388, maxdepth= =3D48) at bytecode.c:678=0A#15 0x010245fb in funcall_lambda (fun=3D49166660= , nargs=3D0, arg_vector=3D0x82f884) at eval.c:3229=0A#16 0x010240cf in Ffun= call (nargs=3D1, args=3D0x82f880) at eval.c:3088=0A#17 0x01023950 in apply1= (fn=3D48517289, arg=3D43722753) at eval.c:2783=0A#18 0x0111a380 in Fcall_i= nteractively (function=3D48517289, record_flag=3D43722753, keys=3D43756292)= at callint.c:389=0A#19 0x01023ee3 in Ffuncall (nargs=3D4, args=3D0x82fb18)= at eval.c:3048=0A#20 0x01023a52 in call3 (fn=3D43917313, arg1=3D48517289, = arg2=3D43722753, arg3=3D43722753) at eval.c:2868=0A#21 0x01015344 in Fcomma= nd_execute (cmd=3D48517289, record_flag=3D43722753, keys=3D43722753, specia= l=3D43722753) at keyboard.c:10420=0A#22 0x01007823 in command_loop_1 () at = keyboard.c:1910=0A#23 0x01021a66 in internal_condition_case (bfun=3D0x10060= cf , handlers=3D43786457, hfun=3D0x1005acc ) at = eval.c:1511=0A#24 0x01005e18 in command_loop_2 () at keyboard.c:1367=0A#25 = 0x01021576 in internal_catch (tag=3D43782529, func=3D0x1005df8 , arg=3D43722753) at eval.c:1247=0A#26 0x01005dcf in command_loop () at= keyboard.c:1346=0A#27 0x010056d2 in recursive_edit_1 () at keyboard.c:955= =0A#28 0x01005840 in Frecursive_edit () at keyboard.c:1017=0A#29 0x010027dc= in main (argc=3D2, argv=3D0xa34290) at emacs.c:1762=0A=0ALisp Backtrace:= =0A"re-search-forward" (0x82ebf4)=0A"auto-coding-regexp-alist-lookup" (0x82= ef04)=0A"find-auto-coding" (0x82f224)=0A"set-auto-coding" (0x82f534)=0A"tar= -extract" (0x82f884)=0A"call-interactively" (0x82fb1c)=0A=0A-dhruva=0A=0A= =0A=0A Unlimited freedom, unlimited storage. Get it now, on http://hel= p.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/