unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).