* 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#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#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#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#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
* 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: 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: 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
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.