* bug#716: 23.0.60; opening tgz file causes emacs crash @ 2008-08-14 8:07 ` robert marshall 2008-08-22 12:10 ` Jason Rumney 2008-12-24 11:30 ` bug#716: marked as done (23.0.60; " Emacs bug Tracking System 0 siblings, 2 replies; 12+ messages in thread From: robert marshall @ 2008-08-14 8:07 UTC (permalink / raw To: emacs-pretest-bug If I open a tgz (tar and gzipped file) in emacs it immediately crashes (giving the windows emacs abort dialog) The file I used to test this was http://download.savannah.gnu.org/releases/viewmail/vm-8.0.11-581.tgz but the problem seemed to occur for other tgz files If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file c:/tmp/emacs/etc/DEBUG for instructions. In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-08-01 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENG value of $XMODIFIERS: nil locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: recentf-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#716: 23.0.60; opening tgz file causes emacs crash 2008-08-14 8:07 ` bug#716: 23.0.60; opening tgz file causes emacs crash robert marshall @ 2008-08-22 12:10 ` Jason Rumney 2008-08-22 16:12 ` Jason Rumney 2008-12-24 11:30 ` bug#716: marked as done (23.0.60; " Emacs bug Tracking System 1 sibling, 1 reply; 12+ messages in thread From: Jason Rumney @ 2008-08-22 12:10 UTC (permalink / raw To: robert marshall, 716 robert marshall wrote: > If I open a tgz (tar and gzipped file) in emacs it immediately crashes > (giving the windows emacs abort dialog) In trying to debug this, I think I have found where it is going wrong, but I have no idea why and how to debug the relevant bytecode. It could be a sign of the byte compilation going wrong on Windows (line-end or other coding problems?), or a bug in Fbytecode somewhere (which is only affecting Windows for some reason). The stack trace when debugging includes the following: #8 0x010a5e65 in Finsert (nargs=2, args=0x0) at editfns.c:2224 #9 0x0115795b in Fbyte_code (bytestr=48986435, vector=49414916, maxdepth=48) at bytecode.c:1265 #10 0x01023232 in funcall_lambda (fun=49839780, nargs=0, arg_vector=0x82d854) at eval.c:3229 #11 0x01022d11 in Ffuncall (nargs=1, args=0x82d850) at eval.c:3088 In frame #11, args[0] is tar-summarize-buffer, so at that point all appears normal. By frame #8 things have clearly gone wrong. How did args become a NULL pointer, yet there are 2 args? Currently I don't have access to a GNU/Linux machine to try a copy of tar-mode.elc compiled there. Can someone else with access to both platforms try that? To reproduce the bug, you need to open a tar file in Emacs (trunk) maybe a few times (the most I have had to open one before triggering the bug is 3 times, but often it happens first time). ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#716: 23.0.60; opening tgz file causes emacs crash 2008-08-22 12:10 ` Jason Rumney @ 2008-08-22 16:12 ` Jason Rumney 2008-09-01 12:12 ` bug#716: Bug in buffer-swap-text (was Re: bug#716: 23.0.60; opening tgz file causes emacs crash) Jason Rumney 0 siblings, 1 reply; 12+ messages in thread From: Jason Rumney @ 2008-08-22 16:12 UTC (permalink / raw To: 716; +Cc: robert marshall Jason Rumney wrote: > In trying to debug this, I think I have found where it is going wrong On further investigation, I think I was seeing symptoms of the problem (smashed stack), not the cause. The NULL argument I observed was inconsistent with the next stack frame up, where the same argument was perfectly valid. The problem starts to occur with version 1.126 of lisp/tar-mode.el. This version contained a rewrite to use separate unibyte and multibyte buffers rather than switching between them in the same buffer. I think something is going wrong here - a possible problems is that the buffer where the crash occurs has a buffer-file-coding-system of iso-latin-1-dos, but my tar program outputs unix line ends (checked by redirecting output to a file, and letting Emacs auto-detect line ends in that file). ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#716: Bug in buffer-swap-text (was Re: bug#716: 23.0.60; opening tgz file causes emacs crash) 2008-08-22 16:12 ` Jason Rumney @ 2008-09-01 12:12 ` Jason Rumney 2008-09-01 12:19 ` Jason Rumney 0 siblings, 1 reply; 12+ messages in thread From: Jason Rumney @ 2008-09-01 12:12 UTC (permalink / raw To: Jason Rumney, 716 I've managed to reduce this to a small test case that shows that the bug is in new function buffer-swap-text. Create the following new buffers: ---- test1.txt ---- This is buffer 1 (buffer-swap-text "test2.txt") ---- test2.txt ---- This is buffer 2 (buffer-swap-text "test2.txt") After creating these buffers, switch to test1.txt buffer and press C-x C-e at the end of the second line. This works fine, and you can swap the two buffers without problem repeatedly. Now, still in test1.txt buffer, C-x RET f binary Now try C-x C-e on the second line again. Perhaps not on the first try, but sooner or later Emacs crashes. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#716: Bug in buffer-swap-text (was Re: bug#716: 23.0.60; opening tgz file causes emacs crash) 2008-09-01 12:12 ` bug#716: Bug in buffer-swap-text (was Re: bug#716: 23.0.60; opening tgz file causes emacs crash) Jason Rumney @ 2008-09-01 12:19 ` Jason Rumney 2008-11-21 15:14 ` Juanma Barranquero 0 siblings, 1 reply; 12+ messages in thread From: Jason Rumney @ 2008-09-01 12:19 UTC (permalink / raw To: Jason Rumney, 716 Jason Rumney wrote: > (buffer-swap-text "test2.txt") Should be (buffer-swap-text (get-buffer "test2.txt")) I've also found that the crash only happens if buffer-swap-text is called from the binary buffer, and only if the other buffer is not binary. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#716: Bug in buffer-swap-text (was Re: bug#716: 23.0.60; opening tgz file causes emacs crash) 2008-09-01 12:19 ` Jason Rumney @ 2008-11-21 15:14 ` Juanma Barranquero 0 siblings, 0 replies; 12+ messages in thread From: Juanma Barranquero @ 2008-11-21 15:14 UTC (permalink / raw To: Jason Rumney, 716 On Mon, Sep 1, 2008 at 13:19, Jason Rumney <jasonr@gnu.org> wrote: > I've also found that the crash only happens if buffer-swap-text is called > from the binary buffer, and only if the other buffer is not binary. I cannot reproduce this bug with your test case; however, the crash opening .tar.gz files is still there. Juanma ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#716: marked as done (23.0.60; opening tgz file causes emacs crash) 2008-08-14 8:07 ` bug#716: 23.0.60; opening tgz file causes emacs crash robert marshall 2008-08-22 12:10 ` Jason Rumney @ 2008-12-24 11:30 ` Emacs bug Tracking System 1 sibling, 0 replies; 12+ messages in thread From: Emacs bug Tracking System @ 2008-12-24 11:30 UTC (permalink / raw To: Jason Rumney [-- Attachment #1: Type: text/plain, Size: 857 bytes --] Your message dated Wed, 24 Dec 2008 19:20:30 +0800 with message-id <49521AFE.4030105@gnu.org> and subject line Re: bug#716: Bug in buffer-swap-text has caused the Emacs bug report #716, regarding 23.0.60; opening tgz file causes emacs crash 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 owner@emacsbugs.donarmstrong.com immediately.) -- 716: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=716 Emacs Bug Tracking System Contact owner@emacsbugs.donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 3586 bytes --] From: robert marshall <robert.marshall@tnei.co.uk> To: emacs-pretest-bug@gnu.org Subject: 23.0.60; opening tgz file causes emacs crash Date: Thu, 14 Aug 2008 09:07:37 +0100 Message-ID: <48A3E7C9.8050509@tnei.co.uk> If I open a tgz (tar and gzipped file) in emacs it immediately crashes (giving the windows emacs abort dialog) The file I used to test this was http://download.savannah.gnu.org/releases/viewmail/vm-8.0.11-581.tgz but the problem seemed to occur for other tgz files If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file c:/tmp/emacs/etc/DEBUG for instructions. In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-08-01 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENG value of $XMODIFIERS: nil locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: recentf-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t [-- Attachment #3: Type: message/rfc822, Size: 3182 bytes --] From: Jason Rumney <jasonr@gnu.org> To: 716-done@emacsbugs.donarmstrong.com Subject: Re: bug#716: Bug in buffer-swap-text Date: Wed, 24 Dec 2008 19:20:30 +0800 Message-ID: <49521AFE.4030105@gnu.org> Stefan Monnier wrote: > Thanks. After your email, I thought we could just change > r_alloc_reset_variable to take 2 arguments: the old ptr and the > new ptr. This way, you get more consistency checking. > I've checked in a change that does this. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#899: 23.0.60; Opening a foo.tar.gz file crashes @ 2008-09-05 23:11 ` Yary Hluchan 2008-12-24 11:30 ` bug#899: marked as done (23.0.60; Opening a foo.tar.gz file crashes) Emacs bug Tracking System 0 siblings, 1 reply; 12+ messages in thread From: Yary Hluchan @ 2008-09-05 23:11 UTC (permalink / raw To: emacs-pretest-bug Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Create a couple small text files- in my case sample1.txt containing: Here is a sample. Hello! and sample2.txt containing: foo bar bat baz put them in an archive with: tar -czf sample.tar.gz sample?.txt Then open a fresh instance of emacs, C-x C-f sample.tar.gz and it crashes. I don't have gdb installed, but I can give you a link to sample.tar.gz http://www.driveway.com/r4h5t5i7r1 My other tar.gz archives also crash emacs. If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file c:/Program Files/Emacs/Unpatched/emacs/etc/DEBUG for instructions. In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-09-03 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU value of $XMODIFIERS: nil locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: recentf-mode: t partial-completion-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: <escape> x r e p o <tab> r <tab> <return> Recent messages: An error has occurred while loading `c:/Documents and Settings/Stephen Edwards/Application Data/.emacs': File error: Cannot open load file, menuacc To ensure normal operation, you should investigate and remove the cause of the error in your initialization file. Start Emacs with the `--debug-init' option to view a complete error backtrace. For information about GNU Emacs and the GNU system, type C-h C-a. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#899: marked as done (23.0.60; Opening a foo.tar.gz file crashes) 2008-09-05 23:11 ` bug#899: 23.0.60; Opening a foo.tar.gz file crashes Yary Hluchan @ 2008-12-24 11:30 ` Emacs bug Tracking System 0 siblings, 0 replies; 12+ messages in thread From: Emacs bug Tracking System @ 2008-12-24 11:30 UTC (permalink / raw To: Jason Rumney [-- Attachment #1: Type: text/plain, Size: 855 bytes --] Your message dated Wed, 24 Dec 2008 19:20:30 +0800 with message-id <49521AFE.4030105@gnu.org> and subject line Re: bug#716: Bug in buffer-swap-text has caused the Emacs bug report #716, regarding 23.0.60; Opening a foo.tar.gz file crashes 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 owner@emacsbugs.donarmstrong.com immediately.) -- 716: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=716 Emacs Bug Tracking System Contact owner@emacsbugs.donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 4211 bytes --] From: Yary Hluchan <yary@apicom.com> To: emacs-pretest-bug@gnu.org Subject: 23.0.60; Opening a foo.tar.gz file crashes Date: Fri, 05 Sep 2008 16:11:12 -0700 Message-ID: <200809052311.m85NBCQk004744@bell.apicom.com> Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Create a couple small text files- in my case sample1.txt containing: Here is a sample. Hello! and sample2.txt containing: foo bar bat baz put them in an archive with: tar -czf sample.tar.gz sample?.txt Then open a fresh instance of emacs, C-x C-f sample.tar.gz and it crashes. I don't have gdb installed, but I can give you a link to sample.tar.gz http://www.driveway.com/r4h5t5i7r1 My other tar.gz archives also crash emacs. If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file c:/Program Files/Emacs/Unpatched/emacs/etc/DEBUG for instructions. In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-09-03 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU value of $XMODIFIERS: nil locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: recentf-mode: t partial-completion-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: <escape> x r e p o <tab> r <tab> <return> Recent messages: An error has occurred while loading `c:/Documents and Settings/Stephen Edwards/Application Data/.emacs': File error: Cannot open load file, menuacc To ensure normal operation, you should investigate and remove the cause of the error in your initialization file. Start Emacs with the `--debug-init' option to view a complete error backtrace. For information about GNU Emacs and the GNU system, type C-h C-a. [-- Attachment #3: Type: message/rfc822, Size: 3182 bytes --] From: Jason Rumney <jasonr@gnu.org> To: 716-done@emacsbugs.donarmstrong.com Subject: Re: bug#716: Bug in buffer-swap-text Date: Wed, 24 Dec 2008 19:20:30 +0800 Message-ID: <49521AFE.4030105@gnu.org> Stefan Monnier wrote: > Thanks. After your email, I thought we could just change > r_alloc_reset_variable to take 2 arguments: the old ptr and the > new ptr. This way, you get more consistency checking. > I've checked in a change that does this. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#1088: 23.0.60; Crash during opening a large .tar.gz file @ 2008-10-05 4:37 ` TAKAHASHI Yoshio 2008-12-24 11:30 ` bug#1088: marked as done (23.0.60; Crash during opening a large .tar.gz file) Emacs bug Tracking System 0 siblings, 1 reply; 12+ messages in thread From: TAKAHASHI Yoshio @ 2008-10-05 4:37 UTC (permalink / raw To: emacs-pretest-bug Emacs crashes when I try to open a large .tar.gz file, in this case it's `w3m-0.5.2.tar.gz'. Emacs crashes during opening a large zip file, too. I use today's cvs head, on below platform: * Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 * build by cygwin/gcc3 "-gdwarf-2 -g3 -mno-cygwin -mtune=pentium4 -O2" Below is the output from `bt full' and `xbacktrace'. [13:25:10]tkh% gdb oo-spd/i386/emacs.exe GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] DISPLAY = TERM = emacs Breakpoint 1 at 0x11535ca: file w32fns.c, line 7272. Breakpoint 2 at 0x109c3c7: file sysdep.c, line 1135. (gdb) run -Q Starting program: /source/emacs/src/emacs23/src/oo-spd/i386/emacs.exe -Q [New thread 3816.0xae0] Error while mapping shared library sections: /source/emacs/src/emacs23/src/External.dll: No such file or directory. Error while mapping shared library sections: /source/emacs/src/emacs23/src/pitadll.dll: No such file or directory. warning: Lowest section in /WINDOWS/system32/mfc42loc.dll is .rsrc at 5f701000 Error while mapping shared library sections: /source/emacs/src/emacs23/src/xkeymacs.dll: No such file or directory. [New thread 3816.0xdfc] Error while mapping shared library sections: /source/emacs/src/emacs23/src/IMJPPRED.DLL: No such file or directory. Error while mapping shared library sections: /source/emacs/src/emacs23/src/VFuj02b1.dll: No such file or directory. [New thread 3816.0x65c] Breakpoint 1, w32_abort () at w32fns.c:7272 7272 button = MessageBox (NULL, (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x7c94120f in ntdll!DbgUiConnectToDbg () from /WINDOWS/system32/ntdll.dll (gdb) bt full #0 0x7c94120f in ntdll!DbgUiConnectToDbg () from /WINDOWS/system32/ntdll.dll No symbol table info available. #1 0x011535fb in w32_abort () at w32fns.c:7286 button = 6 #2 0x0113a4cc in r_re_alloc (ptr=0x389f008, size=8726481) at ralloc.c:1028 bloc = (bloc_ptr) 0x0 #3 0x0106e988 in enlarge_buffer_text (b=0x389f000, delta=-152761) at buffer.c:5071 p = (void *) 0x850608 #4 0x01100c32 in make_gap_smaller (nbytes_removed=-152761) at insdel.c:600 tem = 44251137 real_gap_loc = 8684991 real_gap_loc_byte = 8684991 real_Z = 8724481 real_Z_byte = 8724481 real_beg_unchanged = 1 new_gap_size = 2000 #5 0x01065908 in Fgarbage_collect () at alloc.c:5022 size = 6 nextb = (struct buffer *) 0x389f000 bind = (struct specbinding *) 0x389f000 catch = (struct catchtag *) 0x389f000 handler = (struct handler *) 0x389f000 stack_top_variable = 0 '\0' i = 59371520 message_p = 257 total = {57065480, 7133697, 8579624, 17681473, 59371524, 0, 0, 47669664} t1 = { tv_sec = 8579700, tv_usec = 0 } t2 = { tv_sec = 8579688, tv_usec = 17689956 } t3 = { tv_sec = 0, tv_usec = 0 } #6 0x0100ba70 in Ffuncall (nargs=4, args=0x82eac0) at eval.c:2978 fun = 8579776 original_fun = 3 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x9d, function = 0x2d761a3, args = 0x82ea88, nargs = 17321439, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x3 i = 8717832 #7 0x0111467f in Fbyte_code (bytestr=8717832, vector=8579776, maxdepth=3) at bytecode.c:678 op = 3 vectorp = (Lisp_Object *) 0x2ccfe08 stack = { pc = 0x2d287b2 "\203\177", top = 0x82eacc, bottom = 0x82eac0, byte_string = 53377251, byte_string_start = 0x2d2873c "\b\306\\dX\204\016", constants = 46988804, next = 0x82eca0 } top = (Lisp_Object *) 0x82eac0 #8 0x0100b5a6 in funcall_lambda (fun=50729732, nargs=1, arg_vector=0x82ec54) at eval.c:3231 val = 6 syms_left = 44251137 next = 50729728 i = 1 optional = 0 rest = 0 #9 0x0100ba9b in Ffuncall (nargs=2, args=0x3061304) at eval.c:3101 fun = 50729732 original_fun = 44987633 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82ed50, function = 0x82ec50, args = 0x82ec54, nargs = 1, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x2ae74f1 i = 8717832 #10 0x0111467f in Fbyte_code (bytestr=8717832, vector=8580176, maxdepth=1) at bytecode.c:678 op = 1 vectorp = (Lisp_Object *) 0x304bb08 stack = { pc = 0x2d2a0e2 "\211\025\203\204", top = 0x82ec54, bottom = 0x82ec50, byte_string = 44978531, byte_string_start = 0x2d2a0b4 "\306 \204\v", constants = 50641668, next = 0x82edf0 } top = (Lisp_Object *) 0x82ec50 #11 0x0100b5a6 in funcall_lambda (fun=49815748, nargs=0, arg_vector=0x82eda4) at eval.c:3231 val = 6 syms_left = 44251137 next = 49815744 i = 0 optional = 0 rest = 0 #12 0x0100ba9b in Ffuncall (nargs=1, args=0x2f820c4) at eval.c:3101 fun = 49815748 original_fun = 59665409 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82eea0, function = 0x82eda0, args = 0x82eda4, nargs = 0, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x38e6c01 i = 8717832 #13 0x0111467f in Fbyte_code (bytestr=8717832, vector=8580512, maxdepth=0) at bytecode.c:678 op = 0 vectorp = (Lisp_Object *) 0x304b708 stack = { pc = 0x2d2b4c9 "\210\353\354!\210)\355\356!\207", top = 0x82eda0, bottom = 0x82eda0, byte_string = 44443539, byte_string_start = 0x2d2b434 "\306\300!\210\307\030\310 \210\311\021\312\022\313\v!\210\314\f!\210\r\026/\306\315!\210\306\316!\210\317\026\016\306\320!\210\317\026\020\306\321!\210\317\026\021\306\322!\210\0160\206A", constants = 50640644, next = 0x82ef30 } top = (Lisp_Object *) 0x82eda0 #14 0x0100b5a6 in funcall_lambda (fun=50989380, nargs=0, arg_vector=0x82eef4) at eval.c:3231 val = 6 syms_left = 44251137 next = 50989376 i = 0 optional = 0 rest = 0 #15 0x0100ba9b in Ffuncall (nargs=1, args=0x30a0944) at eval.c:3101 fun = 50989380 original_fun = 53366097 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82efe0, function = 0x82eef0, args = 0x82eef4, nargs = 0, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x32e4d51 i = 8717832 #16 0x0111467f in Fbyte_code (bytestr=8717832, vector=8580848, maxdepth=0) at bytecode.c:678 op = 0 vectorp = (Lisp_Object *) 0x11a6bb8 stack = { pc = 0x129e19b "\210\t\207", top = 0x82eef0, bottom = 0x82eef0, byte_string = 18508707, byte_string_start = 0x129e186 "\b\205\v", constants = 18508724, next = 0x82f080 } top = (Lisp_Object *) 0x82eef0 #17 0x0100b5a6 in funcall_lambda (fun=18508652, nargs=2, arg_vector=0x82f034) at eval.c:3231 val = 6 syms_left = 44251137 next = 18508648 i = 2 optional = 1 rest = 0 #18 0x0100ba9b in Ffuncall (nargs=3, args=0x11a6b6c) at eval.c:3101 fun = 18508652 original_fun = 53375361 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82f210, function = 0x82f030, args = 0x82f034, nargs = 2, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x32e7181 i = 8717832 #19 0x0111467f in Fbyte_code (bytestr=8717832, vector=8581168, maxdepth=2) at bytecode.c:678 op = 2 vectorp = (Lisp_Object *) 0x11a6998 stack = { pc = 0x129e365 "\210\313\022\202\375", top = 0x82f038, bottom = 0x82f030, byte_string = 18508163, byte_string_start = 0x129e205 "\306\211\211\211\030\031\032\033\212eb\210\307\306w\210\f\203s", constants = 18508180, next = 0x82f350 } top = (Lisp_Object *) 0x82f030 #20 0x0100b5a6 in funcall_lambda (fun=18508116, nargs=0, arg_vector=0x82f110) at eval.c:3231 val = 6 syms_left = 44251137 next = 18508112 i = 0 optional = 1 rest = 0 #21 0x0100b823 in apply_lambda (fun=18508116, args=44251137, eval_flag=1) at eval.c:3155 args_left = 44251137 numargs = 0 gcpro1 = { next = 0x1, var = 0x82f1d4, nvars = 0 } gcpro2 = { next = 0x2a5c701, var = 0x117beb8, nvars = 8581560 } gcpro3 = { next = 0x0, var = 0x0, nvars = 59557369 } i = 0 tem = 44251137 #22 0x0100aeeb in Feval (form=18508116) at eval.c:2435 fun = 18508116 val = 8717832 original_fun = 53363025 original_args = 44251137 funcar = 8717832 backtrace = { next = 0x82f400, function = 0x82f1bc, args = 0x82f110, nargs = 0, evalargs = 0 '\0', debug_on_exit = 0 '\0' } gcpro1 = { next = 0x11d1c68, var = 0x1d, nvars = 8581688 } gcpro2 = { next = 0x3, var = 0x0, nvars = 8581536 } gcpro3 = { next = 0x3391204, var = 0x1319c94, nvars = 8581640 } #23 0x0100d4bd in internal_lisp_condition_case (var=44749281, bodyform=18503645, handlers=18503653) at eval.c:1456 val = 44251137 c = { tag = 44251137, val = 44251137, next = 0x82fd80, gcpro = 0x0, jmp = {8581880, 44251137, 8581904, 143, 8581708, 16831515, 8585184, 0, 0, 8581908, 8581632, 19665912, 8582144, 8581904, 8581908, 0}, backlist = 0x82f400, handlerlist = 0x82fd60, lisp_eval_depth = 6, pdlcount = 30, poll_suppress_count = 0, interrupt_input_blocked = 0, byte_stack = 0x82f350 } h = { handler = 18503653, var = 44749281, chosen_clause = 0, tag = 0x82f280, next = 0x82fd60 } #24 0x01114c90 in Fbyte_code (bytestr=8717832, vector=8581904, maxdepth=143) at bytecode.c:868 op = 143 vectorp = (Lisp_Object *) 0x11a5788 stack = { pc = 0x129f306 "\210\v\203'", top = 0x82f310, bottom = 0x82f310, byte_string = 18503539, byte_string_start = 0x129f2ea "\b\206\005", constants = 18503556, next = 0x82f4a0 } top = (Lisp_Object *) 0x82f310 #25 0x0100b5a6 in funcall_lambda (fun=18503492, nargs=1, arg_vector=0x82f454) at eval.c:3231 val = 6 syms_left = 44251137 next = 18503488 i = 1 optional = 1 rest = 0 #26 0x0100ba9b in Ffuncall (nargs=2, args=0x11a5744) at eval.c:3101 fun = 18503492 original_fun = 53362881 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82f550, function = 0x82f450, args = 0x82f454, nargs = 1, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x32e40c1 i = 8717832 #27 0x0111467f in Fbyte_code (bytestr=8717832, vector=8582224, maxdepth=1) at bytecode.c:678 op = 1 vectorp = (Lisp_Object *) 0x11a5500 stack = { pc = 0x129f55d "\210\0165\343>\203", top = 0x82f454, bottom = 0x82f450, byte_string = 18502891, byte_string_start = 0x129f48a "\306\b!?\021\n\204\240", constants = 18502908, next = 0x82f5e0 } top = (Lisp_Object *) 0x82f450 #28 0x0100b5a6 in funcall_lambda (fun=18502812, nargs=2, arg_vector=0x82f5a4) at eval.c:3231 val = 6 syms_left = 44251137 next = 18502808 i = 2 optional = 1 rest = 0 #29 0x0100ba9b in Ffuncall (nargs=3, args=0x11a549c) at eval.c:3101 fun = 18502812 original_fun = 53303089 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82f690, function = 0x82f5a0, args = 0x82f5a4, nargs = 2, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x32d5731 i = 8717832 #30 0x0111467f in Fbyte_code (bytestr=8717832, vector=8582560, maxdepth=2) at bytecode.c:678 op = 2 vectorp = (Lisp_Object *) 0x11a4e20 stack = { pc = 0x129f8d3 "\210p*\207", top = 0x82f5a8, bottom = 0x82f5a0, byte_string = 18501131, byte_string_start = 0x129f843 "\306\030r\tq\210\307\310!\210\307\311!\210\307\312!\210\313\032\314 \210)\315\316!\203&", constants = 18501148, next = 0x82f730 } top = (Lisp_Object *) 0x82f5a0 #31 0x0100b5a6 in funcall_lambda (fun=18501060, nargs=6, arg_vector=0x82f6e4) at eval.c:3231 val = 6 syms_left = 44251137 next = 18501056 i = 6 optional = 0 rest = 0 #32 0x0100ba9b in Ffuncall (nargs=7, args=0x11a4dc4) at eval.c:3101 fun = 18501060 original_fun = 53302969 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82f7e0, function = 0x82f6e0, args = 0x82f6e4, nargs = 6, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x32d56b9 i = 8717832 #33 0x0111467f in Fbyte_code (bytestr=8717832, vector=8582880, maxdepth=6) at bytecode.c:678 op = 6 vectorp = (Lisp_Object *) 0x11a4aa0 stack = { pc = 0x12a021a "-\207", top = 0x82f6f8, bottom = 0x82f6e0, byte_string = 18500235, byte_string_start = 0x129ffa5 "\306\307\b!!\020\310\b!\203(", constants = 18500252, next = 0x82f880 } top = (Lisp_Object *) 0x82f6e0 #34 0x0100b5a6 in funcall_lambda (fun=18500164, nargs=4, arg_vector=0x82f834) at eval.c:3231 val = 6 syms_left = 44251137 next = 18500160 i = 4 optional = 1 rest = 0 #35 0x0100ba9b in Ffuncall (nargs=5, args=0x11a4a44) at eval.c:3101 fun = 18500164 original_fun = 53303945 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82f930, function = 0x82f830, args = 0x82f834, nargs = 4, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x32d5a89 i = 8717832 #36 0x0111467f in Fbyte_code (bytestr=8717832, vector=8583216, maxdepth=4) at bytecode.c:678 op = 4 vectorp = (Lisp_Object *) 0x11a36a0 stack = { pc = 0x12a0973 "\211\032<\203\024", top = 0x82f840, bottom = 0x82f830, byte_string = 18495115, byte_string_start = 0x12a096d "\303\b\304\211\t$\211\032<\203\024", constants = 18495132, next = 0x0 } top = (Lisp_Object *) 0x82f830 #37 0x0100b5a6 in funcall_lambda (fun=18495060, nargs=2, arg_vector=0x82f984) at eval.c:3231 val = 6 syms_left = 44251137 next = 18495056 i = 2 optional = 1 rest = 0 #38 0x0100ba9b in Ffuncall (nargs=3, args=0x11a3654) at eval.c:3101 fun = 18495060 original_fun = 53270529 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82fbb0, function = 0x82f980, args = 0x82f984, nargs = 2, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x32cd801 i = 8717832 #39 0x0100d09d in Fapply (nargs=2, args=0x82f9f8) at eval.c:2532 i = 3 numargs = 2 spread_arg = 44251137 funcall_args = (Lisp_Object *) 0x82f980 fun = 18495060 gcpro1 = { next = 0x3, var = 0x0, nvars = 3 } #40 0x0100d1ee in apply1 (fn=53270529, arg=8717832) at eval.c:2793 args = {53270529, 59221669} gcpro1 = { next = 0x10516a7, var = 0x82f9f8, nvars = 2 } #41 0x011125e1 in Fcall_interactively (function=53270529, record_flag=44251137, keys=44284676) at callint.c:389 specs = 59221669 filter_specs = 53270529 teml = 53270529 up_event = 44251137 enable = 44251137 next_event = 18054281 prefix_arg = 44251137 string = (unsigned char *) 0x2a5d861 "" tem = (unsigned char *) 0x2a3ef79 "" i = 2 j = 44251137 foo = 6 prompt1 = "\001\000\000\000|\373\202\000\210\373\202\000[\360\v\001\0018\243\002\001\000\000\000\001\000\000\000\000\320\243\002\0018\243\002|\373\202\000\002\000\000\000\270\276\027\001\000\000\000\000x\373\202\000|\373\202\000\001\000\000\000\000\000\000\000\001\000\000\000B\000\000\000\377\377\377\377\376\377\377\377\037\000\000\000h\373\202\000\002\000\000\000\001\330,\003" arg_from_tty = 0 gcpro1 = { next = 0x2a5c701, var = 0x117beb8, nvars = 8584024 } gcpro2 = { next = 0x0, var = 0x2a40921, nvars = 58661321 } gcpro3 = { next = 0x1, var = 0x82fb7c, nvars = 8583912 } gcpro4 = { next = 0x2ae9f0d, var = 0x2a40951, nvars = 8583896 } gcpro5 = { next = 0x2a3e659, var = 0x2a30d4d, nvars = 8583912 } key_count = 2 record_then_fail = 0 save_this_command = 53270529 save_last_command = 44251137 save_this_original_command = 53270529 save_real_this_command = 53270529 #42 0x0100bc95 in Ffuncall (nargs=4, args=0x12c1bd8) at eval.c:3050 fun = 19667928 original_fun = 8584196 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x0, function = 0x82fc00, args = 0x82fc04, nargs = 3, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x82fc04 i = 8717832 #43 0x0100be6d in call3 (fn=6, arg1=6, arg2=6, arg3=6) at eval.c:2870 ret_ungc_val = 6 gcpro1 = { next = 0x2a5c509, var = 0x2a33801, nvars = 4 } args = {44445793, 53270529, 44251137, 44251137} #44 0x0105696f in Fcommand_execute (cmd=53270529, record_flag=44251137, keys=6, special=44251137) at keyboard.c:10332 final = 18495056 tem = 8717832 prefixarg = 44251137 #45 0x0105e14a in command_loop_1 () at keyboard.c:1880 cmd = 2 lose = 2 nonundocount = 0 keybuf = {192, 48, 2, 12, 0, 2, 8584752, 0, 8584756, 0 <repeats 12 times>, 8584364, 8584192, 0, 0, 0, 84, 0, 234881024, 84} i = 44486272 prev_modiff = 11 prev_buffer = (struct buffer *) 0x2a3d000 already_adjusted = 0 #46 0x01009e22 in internal_condition_case (bfun=0x105dde5 <command_loop_1>, handlers=44314889, hfun=0x10573e5 <cmd_error>) at eval.c:1511 val = 6 c = { tag = 44251137, val = 44251137, next = 0x82fe30, gcpro = 0x0, jmp = {8584696, 0, 19966966, 1, 8584524, 16817615, 8585184, 0, 152, 0, 0, 44389888, 0, 1, 0, 17377108}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 0, interrupt_input_blocked = 0, byte_stack = 0x0 } h = { handler = 44314889, var = 44251137, chosen_clause = 2088805529, tag = 0x82fd80, next = 0x0 } #47 0x01051972 in command_loop_2 () at keyboard.c:1338 val = 6 #48 0x01009d57 in internal_catch (tag=6, func=0x105194f <command_loop_2>, arg=44251137) at eval.c:1247 c = { tag = 44310961, val = 44251137, next = 0x0, gcpro = 0x0, jmp = {8584872, 0, 19966966, 1, 8584732, 16817469, 8585184, 0, 44528785, 44527954, 44251137, 44290048, 0, 0, 0, 44251137}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 0, interrupt_input_blocked = 0, byte_stack = 0x0 } #49 0x0105177f in command_loop () at keyboard.c:1317 No locals. #50 0x01051818 in recursive_edit_1 () at keyboard.c:942 val = 0 #51 0x01051939 in Frecursive_edit () at keyboard.c:1004 buffer = 44251137 #52 0x01002a70 in main (argc=2, argv=0xa92758) at emacs.c:1725 dummy = 8585080 stack_bottom_variable = 119 'w' do_initial_setlocale = 1 skip_args = 0 no_loadup = 0 junk = 0x0 Lisp Backtrace: "tar-header-block-tokenize" (0x82ec54) "tar-summarize-buffer" (0x82eda4) "tar-mode" (0x82eef4) "set-auto-mode-0" (0x82f034) "set-auto-mode" (0x82f110) "normal-mode" (0x82f454) "after-find-file" (0x82f5a4) "find-file-noselect-1" (0x82f6e4) "find-file-noselect" (0x82f834) "find-file" (0x82f984) "call-interactively" (0x82fc04) (gdb) xbacktrace "tar-header-block-tokenize" (0x82ec54) "tar-summarize-buffer" (0x82eda4) "tar-mode" (0x82eef4) "set-auto-mode-0" (0x82f034) "set-auto-mode" (0x82f110) "normal-mode" (0x82f454) "after-find-file" (0x82f5a4) "find-file-noselect-1" (0x82f6e4) "find-file-noselect" (0x82f834) "find-file" (0x82f984) "call-interactively" (0x82fc04) (gdb) quit The program is running. Exit anyway? (y or n) [answered Y; input not from terminal] [13:26:20]tkh% ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#1088: marked as done (23.0.60; Crash during opening a large .tar.gz file) 2008-10-05 4:37 ` bug#1088: 23.0.60; Crash during opening a large .tar.gz file TAKAHASHI Yoshio @ 2008-12-24 11:30 ` Emacs bug Tracking System 0 siblings, 0 replies; 12+ messages in thread From: Emacs bug Tracking System @ 2008-12-24 11:30 UTC (permalink / raw To: Jason Rumney [-- Attachment #1: Type: text/plain, Size: 863 bytes --] Your message dated Wed, 24 Dec 2008 19:20:30 +0800 with message-id <49521AFE.4030105@gnu.org> and subject line Re: bug#716: Bug in buffer-swap-text has caused the Emacs bug report #716, regarding 23.0.60; Crash during opening a large .tar.gz file 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 owner@emacsbugs.donarmstrong.com immediately.) -- 716: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=716 Emacs Bug Tracking System Contact owner@emacsbugs.donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 21508 bytes --] From: TAKAHASHI Yoshio <yfb02119@nifty.com> To: emacs-pretest-bug@gnu.org Subject: 23.0.60; Crash during opening a large .tar.gz file Date: Sun, 05 Oct 2008 13:37:45 +0900 Message-ID: <7zzlljzmg6.fsf@yfb02119.nifty.com> Emacs crashes when I try to open a large .tar.gz file, in this case it's `w3m-0.5.2.tar.gz'. Emacs crashes during opening a large zip file, too. I use today's cvs head, on below platform: * Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 * build by cygwin/gcc3 "-gdwarf-2 -g3 -mno-cygwin -mtune=pentium4 -O2" Below is the output from `bt full' and `xbacktrace'. [13:25:10]tkh% gdb oo-spd/i386/emacs.exe GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] DISPLAY = TERM = emacs Breakpoint 1 at 0x11535ca: file w32fns.c, line 7272. Breakpoint 2 at 0x109c3c7: file sysdep.c, line 1135. (gdb) run -Q Starting program: /source/emacs/src/emacs23/src/oo-spd/i386/emacs.exe -Q [New thread 3816.0xae0] Error while mapping shared library sections: /source/emacs/src/emacs23/src/External.dll: No such file or directory. Error while mapping shared library sections: /source/emacs/src/emacs23/src/pitadll.dll: No such file or directory. warning: Lowest section in /WINDOWS/system32/mfc42loc.dll is .rsrc at 5f701000 Error while mapping shared library sections: /source/emacs/src/emacs23/src/xkeymacs.dll: No such file or directory. [New thread 3816.0xdfc] Error while mapping shared library sections: /source/emacs/src/emacs23/src/IMJPPRED.DLL: No such file or directory. Error while mapping shared library sections: /source/emacs/src/emacs23/src/VFuj02b1.dll: No such file or directory. [New thread 3816.0x65c] Breakpoint 1, w32_abort () at w32fns.c:7272 7272 button = MessageBox (NULL, (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x7c94120f in ntdll!DbgUiConnectToDbg () from /WINDOWS/system32/ntdll.dll (gdb) bt full #0 0x7c94120f in ntdll!DbgUiConnectToDbg () from /WINDOWS/system32/ntdll.dll No symbol table info available. #1 0x011535fb in w32_abort () at w32fns.c:7286 button = 6 #2 0x0113a4cc in r_re_alloc (ptr=0x389f008, size=8726481) at ralloc.c:1028 bloc = (bloc_ptr) 0x0 #3 0x0106e988 in enlarge_buffer_text (b=0x389f000, delta=-152761) at buffer.c:5071 p = (void *) 0x850608 #4 0x01100c32 in make_gap_smaller (nbytes_removed=-152761) at insdel.c:600 tem = 44251137 real_gap_loc = 8684991 real_gap_loc_byte = 8684991 real_Z = 8724481 real_Z_byte = 8724481 real_beg_unchanged = 1 new_gap_size = 2000 #5 0x01065908 in Fgarbage_collect () at alloc.c:5022 size = 6 nextb = (struct buffer *) 0x389f000 bind = (struct specbinding *) 0x389f000 catch = (struct catchtag *) 0x389f000 handler = (struct handler *) 0x389f000 stack_top_variable = 0 '\0' i = 59371520 message_p = 257 total = {57065480, 7133697, 8579624, 17681473, 59371524, 0, 0, 47669664} t1 = { tv_sec = 8579700, tv_usec = 0 } t2 = { tv_sec = 8579688, tv_usec = 17689956 } t3 = { tv_sec = 0, tv_usec = 0 } #6 0x0100ba70 in Ffuncall (nargs=4, args=0x82eac0) at eval.c:2978 fun = 8579776 original_fun = 3 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x9d, function = 0x2d761a3, args = 0x82ea88, nargs = 17321439, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x3 i = 8717832 #7 0x0111467f in Fbyte_code (bytestr=8717832, vector=8579776, maxdepth=3) at bytecode.c:678 op = 3 vectorp = (Lisp_Object *) 0x2ccfe08 stack = { pc = 0x2d287b2 "\203\177", top = 0x82eacc, bottom = 0x82eac0, byte_string = 53377251, byte_string_start = 0x2d2873c "\b\306\\dX\204\016", constants = 46988804, next = 0x82eca0 } top = (Lisp_Object *) 0x82eac0 #8 0x0100b5a6 in funcall_lambda (fun=50729732, nargs=1, arg_vector=0x82ec54) at eval.c:3231 val = 6 syms_left = 44251137 next = 50729728 i = 1 optional = 0 rest = 0 #9 0x0100ba9b in Ffuncall (nargs=2, args=0x3061304) at eval.c:3101 fun = 50729732 original_fun = 44987633 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82ed50, function = 0x82ec50, args = 0x82ec54, nargs = 1, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x2ae74f1 i = 8717832 #10 0x0111467f in Fbyte_code (bytestr=8717832, vector=8580176, maxdepth=1) at bytecode.c:678 op = 1 vectorp = (Lisp_Object *) 0x304bb08 stack = { pc = 0x2d2a0e2 "\211\025\203\204", top = 0x82ec54, bottom = 0x82ec50, byte_string = 44978531, byte_string_start = 0x2d2a0b4 "\306 \204\v", constants = 50641668, next = 0x82edf0 } top = (Lisp_Object *) 0x82ec50 #11 0x0100b5a6 in funcall_lambda (fun=49815748, nargs=0, arg_vector=0x82eda4) at eval.c:3231 val = 6 syms_left = 44251137 next = 49815744 i = 0 optional = 0 rest = 0 #12 0x0100ba9b in Ffuncall (nargs=1, args=0x2f820c4) at eval.c:3101 fun = 49815748 original_fun = 59665409 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82eea0, function = 0x82eda0, args = 0x82eda4, nargs = 0, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x38e6c01 i = 8717832 #13 0x0111467f in Fbyte_code (bytestr=8717832, vector=8580512, maxdepth=0) at bytecode.c:678 op = 0 vectorp = (Lisp_Object *) 0x304b708 stack = { pc = 0x2d2b4c9 "\210\353\354!\210)\355\356!\207", top = 0x82eda0, bottom = 0x82eda0, byte_string = 44443539, byte_string_start = 0x2d2b434 "\306\300!\210\307\030\310 \210\311\021\312\022\313\v!\210\314\f!\210\r\026/\306\315!\210\306\316!\210\317\026\016\306\320!\210\317\026\020\306\321!\210\317\026\021\306\322!\210\0160\206A", constants = 50640644, next = 0x82ef30 } top = (Lisp_Object *) 0x82eda0 #14 0x0100b5a6 in funcall_lambda (fun=50989380, nargs=0, arg_vector=0x82eef4) at eval.c:3231 val = 6 syms_left = 44251137 next = 50989376 i = 0 optional = 0 rest = 0 #15 0x0100ba9b in Ffuncall (nargs=1, args=0x30a0944) at eval.c:3101 fun = 50989380 original_fun = 53366097 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82efe0, function = 0x82eef0, args = 0x82eef4, nargs = 0, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x32e4d51 i = 8717832 #16 0x0111467f in Fbyte_code (bytestr=8717832, vector=8580848, maxdepth=0) at bytecode.c:678 op = 0 vectorp = (Lisp_Object *) 0x11a6bb8 stack = { pc = 0x129e19b "\210\t\207", top = 0x82eef0, bottom = 0x82eef0, byte_string = 18508707, byte_string_start = 0x129e186 "\b\205\v", constants = 18508724, next = 0x82f080 } top = (Lisp_Object *) 0x82eef0 #17 0x0100b5a6 in funcall_lambda (fun=18508652, nargs=2, arg_vector=0x82f034) at eval.c:3231 val = 6 syms_left = 44251137 next = 18508648 i = 2 optional = 1 rest = 0 #18 0x0100ba9b in Ffuncall (nargs=3, args=0x11a6b6c) at eval.c:3101 fun = 18508652 original_fun = 53375361 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82f210, function = 0x82f030, args = 0x82f034, nargs = 2, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x32e7181 i = 8717832 #19 0x0111467f in Fbyte_code (bytestr=8717832, vector=8581168, maxdepth=2) at bytecode.c:678 op = 2 vectorp = (Lisp_Object *) 0x11a6998 stack = { pc = 0x129e365 "\210\313\022\202\375", top = 0x82f038, bottom = 0x82f030, byte_string = 18508163, byte_string_start = 0x129e205 "\306\211\211\211\030\031\032\033\212eb\210\307\306w\210\f\203s", constants = 18508180, next = 0x82f350 } top = (Lisp_Object *) 0x82f030 #20 0x0100b5a6 in funcall_lambda (fun=18508116, nargs=0, arg_vector=0x82f110) at eval.c:3231 val = 6 syms_left = 44251137 next = 18508112 i = 0 optional = 1 rest = 0 #21 0x0100b823 in apply_lambda (fun=18508116, args=44251137, eval_flag=1) at eval.c:3155 args_left = 44251137 numargs = 0 gcpro1 = { next = 0x1, var = 0x82f1d4, nvars = 0 } gcpro2 = { next = 0x2a5c701, var = 0x117beb8, nvars = 8581560 } gcpro3 = { next = 0x0, var = 0x0, nvars = 59557369 } i = 0 tem = 44251137 #22 0x0100aeeb in Feval (form=18508116) at eval.c:2435 fun = 18508116 val = 8717832 original_fun = 53363025 original_args = 44251137 funcar = 8717832 backtrace = { next = 0x82f400, function = 0x82f1bc, args = 0x82f110, nargs = 0, evalargs = 0 '\0', debug_on_exit = 0 '\0' } gcpro1 = { next = 0x11d1c68, var = 0x1d, nvars = 8581688 } gcpro2 = { next = 0x3, var = 0x0, nvars = 8581536 } gcpro3 = { next = 0x3391204, var = 0x1319c94, nvars = 8581640 } #23 0x0100d4bd in internal_lisp_condition_case (var=44749281, bodyform=18503645, handlers=18503653) at eval.c:1456 val = 44251137 c = { tag = 44251137, val = 44251137, next = 0x82fd80, gcpro = 0x0, jmp = {8581880, 44251137, 8581904, 143, 8581708, 16831515, 8585184, 0, 0, 8581908, 8581632, 19665912, 8582144, 8581904, 8581908, 0}, backlist = 0x82f400, handlerlist = 0x82fd60, lisp_eval_depth = 6, pdlcount = 30, poll_suppress_count = 0, interrupt_input_blocked = 0, byte_stack = 0x82f350 } h = { handler = 18503653, var = 44749281, chosen_clause = 0, tag = 0x82f280, next = 0x82fd60 } #24 0x01114c90 in Fbyte_code (bytestr=8717832, vector=8581904, maxdepth=143) at bytecode.c:868 op = 143 vectorp = (Lisp_Object *) 0x11a5788 stack = { pc = 0x129f306 "\210\v\203'", top = 0x82f310, bottom = 0x82f310, byte_string = 18503539, byte_string_start = 0x129f2ea "\b\206\005", constants = 18503556, next = 0x82f4a0 } top = (Lisp_Object *) 0x82f310 #25 0x0100b5a6 in funcall_lambda (fun=18503492, nargs=1, arg_vector=0x82f454) at eval.c:3231 val = 6 syms_left = 44251137 next = 18503488 i = 1 optional = 1 rest = 0 #26 0x0100ba9b in Ffuncall (nargs=2, args=0x11a5744) at eval.c:3101 fun = 18503492 original_fun = 53362881 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82f550, function = 0x82f450, args = 0x82f454, nargs = 1, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x32e40c1 i = 8717832 #27 0x0111467f in Fbyte_code (bytestr=8717832, vector=8582224, maxdepth=1) at bytecode.c:678 op = 1 vectorp = (Lisp_Object *) 0x11a5500 stack = { pc = 0x129f55d "\210\0165\343>\203", top = 0x82f454, bottom = 0x82f450, byte_string = 18502891, byte_string_start = 0x129f48a "\306\b!?\021\n\204\240", constants = 18502908, next = 0x82f5e0 } top = (Lisp_Object *) 0x82f450 #28 0x0100b5a6 in funcall_lambda (fun=18502812, nargs=2, arg_vector=0x82f5a4) at eval.c:3231 val = 6 syms_left = 44251137 next = 18502808 i = 2 optional = 1 rest = 0 #29 0x0100ba9b in Ffuncall (nargs=3, args=0x11a549c) at eval.c:3101 fun = 18502812 original_fun = 53303089 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82f690, function = 0x82f5a0, args = 0x82f5a4, nargs = 2, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x32d5731 i = 8717832 #30 0x0111467f in Fbyte_code (bytestr=8717832, vector=8582560, maxdepth=2) at bytecode.c:678 op = 2 vectorp = (Lisp_Object *) 0x11a4e20 stack = { pc = 0x129f8d3 "\210p*\207", top = 0x82f5a8, bottom = 0x82f5a0, byte_string = 18501131, byte_string_start = 0x129f843 "\306\030r\tq\210\307\310!\210\307\311!\210\307\312!\210\313\032\314 \210)\315\316!\203&", constants = 18501148, next = 0x82f730 } top = (Lisp_Object *) 0x82f5a0 #31 0x0100b5a6 in funcall_lambda (fun=18501060, nargs=6, arg_vector=0x82f6e4) at eval.c:3231 val = 6 syms_left = 44251137 next = 18501056 i = 6 optional = 0 rest = 0 #32 0x0100ba9b in Ffuncall (nargs=7, args=0x11a4dc4) at eval.c:3101 fun = 18501060 original_fun = 53302969 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82f7e0, function = 0x82f6e0, args = 0x82f6e4, nargs = 6, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x32d56b9 i = 8717832 #33 0x0111467f in Fbyte_code (bytestr=8717832, vector=8582880, maxdepth=6) at bytecode.c:678 op = 6 vectorp = (Lisp_Object *) 0x11a4aa0 stack = { pc = 0x12a021a "-\207", top = 0x82f6f8, bottom = 0x82f6e0, byte_string = 18500235, byte_string_start = 0x129ffa5 "\306\307\b!!\020\310\b!\203(", constants = 18500252, next = 0x82f880 } top = (Lisp_Object *) 0x82f6e0 #34 0x0100b5a6 in funcall_lambda (fun=18500164, nargs=4, arg_vector=0x82f834) at eval.c:3231 val = 6 syms_left = 44251137 next = 18500160 i = 4 optional = 1 rest = 0 #35 0x0100ba9b in Ffuncall (nargs=5, args=0x11a4a44) at eval.c:3101 fun = 18500164 original_fun = 53303945 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82f930, function = 0x82f830, args = 0x82f834, nargs = 4, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x32d5a89 i = 8717832 #36 0x0111467f in Fbyte_code (bytestr=8717832, vector=8583216, maxdepth=4) at bytecode.c:678 op = 4 vectorp = (Lisp_Object *) 0x11a36a0 stack = { pc = 0x12a0973 "\211\032<\203\024", top = 0x82f840, bottom = 0x82f830, byte_string = 18495115, byte_string_start = 0x12a096d "\303\b\304\211\t$\211\032<\203\024", constants = 18495132, next = 0x0 } top = (Lisp_Object *) 0x82f830 #37 0x0100b5a6 in funcall_lambda (fun=18495060, nargs=2, arg_vector=0x82f984) at eval.c:3231 val = 6 syms_left = 44251137 next = 18495056 i = 2 optional = 1 rest = 0 #38 0x0100ba9b in Ffuncall (nargs=3, args=0x11a3654) at eval.c:3101 fun = 18495060 original_fun = 53270529 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x82fbb0, function = 0x82f980, args = 0x82f984, nargs = 2, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x32cd801 i = 8717832 #39 0x0100d09d in Fapply (nargs=2, args=0x82f9f8) at eval.c:2532 i = 3 numargs = 2 spread_arg = 44251137 funcall_args = (Lisp_Object *) 0x82f980 fun = 18495060 gcpro1 = { next = 0x3, var = 0x0, nvars = 3 } #40 0x0100d1ee in apply1 (fn=53270529, arg=8717832) at eval.c:2793 args = {53270529, 59221669} gcpro1 = { next = 0x10516a7, var = 0x82f9f8, nvars = 2 } #41 0x011125e1 in Fcall_interactively (function=53270529, record_flag=44251137, keys=44284676) at callint.c:389 specs = 59221669 filter_specs = 53270529 teml = 53270529 up_event = 44251137 enable = 44251137 next_event = 18054281 prefix_arg = 44251137 string = (unsigned char *) 0x2a5d861 "" tem = (unsigned char *) 0x2a3ef79 "" i = 2 j = 44251137 foo = 6 prompt1 = "\001\000\000\000|\373\202\000\210\373\202\000[\360\v\001\0018\243\002\001\000\000\000\001\000\000\000\000\320\243\002\0018\243\002|\373\202\000\002\000\000\000\270\276\027\001\000\000\000\000x\373\202\000|\373\202\000\001\000\000\000\000\000\000\000\001\000\000\000B\000\000\000\377\377\377\377\376\377\377\377\037\000\000\000h\373\202\000\002\000\000\000\001\330,\003" arg_from_tty = 0 gcpro1 = { next = 0x2a5c701, var = 0x117beb8, nvars = 8584024 } gcpro2 = { next = 0x0, var = 0x2a40921, nvars = 58661321 } gcpro3 = { next = 0x1, var = 0x82fb7c, nvars = 8583912 } gcpro4 = { next = 0x2ae9f0d, var = 0x2a40951, nvars = 8583896 } gcpro5 = { next = 0x2a3e659, var = 0x2a30d4d, nvars = 8583912 } key_count = 2 record_then_fail = 0 save_this_command = 53270529 save_last_command = 44251137 save_this_original_command = 53270529 save_real_this_command = 53270529 #42 0x0100bc95 in Ffuncall (nargs=4, args=0x12c1bd8) at eval.c:3050 fun = 19667928 original_fun = 8584196 funcar = 8717832 lisp_numargs = 6 val = 8717832 backtrace = { next = 0x0, function = 0x82fc00, args = 0x82fc04, nargs = 3, evalargs = 0 '\0', debug_on_exit = 0 '\0' } internal_args = (Lisp_Object *) 0x82fc04 i = 8717832 #43 0x0100be6d in call3 (fn=6, arg1=6, arg2=6, arg3=6) at eval.c:2870 ret_ungc_val = 6 gcpro1 = { next = 0x2a5c509, var = 0x2a33801, nvars = 4 } args = {44445793, 53270529, 44251137, 44251137} #44 0x0105696f in Fcommand_execute (cmd=53270529, record_flag=44251137, keys=6, special=44251137) at keyboard.c:10332 final = 18495056 tem = 8717832 prefixarg = 44251137 #45 0x0105e14a in command_loop_1 () at keyboard.c:1880 cmd = 2 lose = 2 nonundocount = 0 keybuf = {192, 48, 2, 12, 0, 2, 8584752, 0, 8584756, 0 <repeats 12 times>, 8584364, 8584192, 0, 0, 0, 84, 0, 234881024, 84} i = 44486272 prev_modiff = 11 prev_buffer = (struct buffer *) 0x2a3d000 already_adjusted = 0 #46 0x01009e22 in internal_condition_case (bfun=0x105dde5 <command_loop_1>, handlers=44314889, hfun=0x10573e5 <cmd_error>) at eval.c:1511 val = 6 c = { tag = 44251137, val = 44251137, next = 0x82fe30, gcpro = 0x0, jmp = {8584696, 0, 19966966, 1, 8584524, 16817615, 8585184, 0, 152, 0, 0, 44389888, 0, 1, 0, 17377108}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 0, interrupt_input_blocked = 0, byte_stack = 0x0 } h = { handler = 44314889, var = 44251137, chosen_clause = 2088805529, tag = 0x82fd80, next = 0x0 } #47 0x01051972 in command_loop_2 () at keyboard.c:1338 val = 6 #48 0x01009d57 in internal_catch (tag=6, func=0x105194f <command_loop_2>, arg=44251137) at eval.c:1247 c = { tag = 44310961, val = 44251137, next = 0x0, gcpro = 0x0, jmp = {8584872, 0, 19966966, 1, 8584732, 16817469, 8585184, 0, 44528785, 44527954, 44251137, 44290048, 0, 0, 0, 44251137}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 0, interrupt_input_blocked = 0, byte_stack = 0x0 } #49 0x0105177f in command_loop () at keyboard.c:1317 No locals. #50 0x01051818 in recursive_edit_1 () at keyboard.c:942 val = 0 #51 0x01051939 in Frecursive_edit () at keyboard.c:1004 buffer = 44251137 #52 0x01002a70 in main (argc=2, argv=0xa92758) at emacs.c:1725 dummy = 8585080 stack_bottom_variable = 119 'w' do_initial_setlocale = 1 skip_args = 0 no_loadup = 0 junk = 0x0 Lisp Backtrace: "tar-header-block-tokenize" (0x82ec54) "tar-summarize-buffer" (0x82eda4) "tar-mode" (0x82eef4) "set-auto-mode-0" (0x82f034) "set-auto-mode" (0x82f110) "normal-mode" (0x82f454) "after-find-file" (0x82f5a4) "find-file-noselect-1" (0x82f6e4) "find-file-noselect" (0x82f834) "find-file" (0x82f984) "call-interactively" (0x82fc04) (gdb) xbacktrace "tar-header-block-tokenize" (0x82ec54) "tar-summarize-buffer" (0x82eda4) "tar-mode" (0x82eef4) "set-auto-mode-0" (0x82f034) "set-auto-mode" (0x82f110) "normal-mode" (0x82f454) "after-find-file" (0x82f5a4) "find-file-noselect-1" (0x82f6e4) "find-file-noselect" (0x82f834) "find-file" (0x82f984) "call-interactively" (0x82fc04) (gdb) quit The program is running. Exit anyway? (y or n) [answered Y; input not from terminal] [13:26:20]tkh% [-- Attachment #3: Type: message/rfc822, Size: 3182 bytes --] From: Jason Rumney <jasonr@gnu.org> To: 716-done@emacsbugs.donarmstrong.com Subject: Re: bug#716: Bug in buffer-swap-text Date: Wed, 24 Dec 2008 19:20:30 +0800 Message-ID: <49521AFE.4030105@gnu.org> Stefan Monnier wrote: > Thanks. After your email, I thought we could just change > r_alloc_reset_variable to take 2 arguments: the old ptr and the > new ptr. This way, you get more consistency checking. > I've checked in a change that does this. ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <as3akqfb8k.fsf@fencepost.gnu.org>]
* bug#805: marked as done (Emacs crashes on Windows when visiting .tar.gz files) [not found] ` <as3akqfb8k.fsf@fencepost.gnu.org> @ 2008-12-24 11:30 ` Emacs bug Tracking System 0 siblings, 0 replies; 12+ messages in thread From: Emacs bug Tracking System @ 2008-12-24 11:30 UTC (permalink / raw To: Jason Rumney [-- Attachment #1: Type: text/plain, Size: 865 bytes --] Your message dated Wed, 24 Dec 2008 19:20:30 +0800 with message-id <49521AFE.4030105@gnu.org> and subject line Re: bug#716: Bug in buffer-swap-text has caused the Emacs bug report #716, regarding Emacs crashes on Windows when visiting .tar.gz files 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 owner@emacsbugs.donarmstrong.com immediately.) -- 716: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=716 Emacs Bug Tracking System Contact owner@emacsbugs.donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 1962 bytes --] From: Glenn Morris <rgm@gnu.org> To: quiet <quiet@emacsbugs.donarmstrong.com> Subject: Emacs crashes on Windows when visiting .tar.gz files Date: Wed, 27 Aug 2008 16:34:35 -0400 Message-ID: <as3akqfb8k.fsf@fencepost.gnu.org> Package: emacs,w32 (Filing a report for old item from FOR-RELEASE.) http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg01850.html Initial report: Steps to reproduce: 1. Create a small tar file with 2 or 3 files in it 2. emacs -q 3. M-x load-library tar-mode 4. Open the tar file You see the crash (with earlier posted stack trace) I saw another crash with the following steps: 1. Repeat #1, #2 from the previous scenario 2. Open the tar file, you will see the file listing 3. Position the cursor on one of the listed files and hit enter (open the file in the archive) You see a crash. Stack trace follows for 2nd scenario: [-- Attachment #3: Type: message/rfc822, Size: 3182 bytes --] From: Jason Rumney <jasonr@gnu.org> To: 716-done@emacsbugs.donarmstrong.com Subject: Re: bug#716: Bug in buffer-swap-text Date: Wed, 24 Dec 2008 19:20:30 +0800 Message-ID: <49521AFE.4030105@gnu.org> Stefan Monnier wrote: > Thanks. After your email, I thought we could just change > r_alloc_reset_variable to take 2 arguments: the old ptr and the > new ptr. This way, you get more consistency checking. > I've checked in a change that does this. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2008-12-24 11:30 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <49521AFE.4030105@gnu.org> 2008-08-14 8:07 ` bug#716: 23.0.60; opening tgz file causes emacs crash robert marshall 2008-08-22 12:10 ` Jason Rumney 2008-08-22 16:12 ` Jason Rumney 2008-09-01 12:12 ` bug#716: Bug in buffer-swap-text (was Re: bug#716: 23.0.60; opening tgz file causes emacs crash) Jason Rumney 2008-09-01 12:19 ` Jason Rumney 2008-11-21 15:14 ` Juanma Barranquero 2008-12-24 11:30 ` bug#716: marked as done (23.0.60; " Emacs bug Tracking System 2008-09-05 23:11 ` bug#899: 23.0.60; Opening a foo.tar.gz file crashes Yary Hluchan 2008-12-24 11:30 ` bug#899: marked as done (23.0.60; Opening a foo.tar.gz file crashes) Emacs bug Tracking System 2008-10-05 4:37 ` bug#1088: 23.0.60; Crash during opening a large .tar.gz file TAKAHASHI Yoshio 2008-12-24 11:30 ` bug#1088: marked as done (23.0.60; Crash during opening a large .tar.gz file) Emacs bug Tracking System [not found] ` <as3akqfb8k.fsf@fencepost.gnu.org> 2008-12-24 11:30 ` bug#805: marked as done (Emacs crashes on Windows when visiting .tar.gz files) Emacs bug Tracking System
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.