* bug#1787: marked as done (23.0.60; `concat' with longer strings aborts Emacs ungracefully )
2009-01-05 1:23 ` bug#1787: 23.0.60; `concat' with longer strings aborts Emacs ungracefully Markus Triska
@ 2009-01-27 21:25 ` Emacs bug Tracking System
0 siblings, 0 replies; 2+ messages in thread
From: Emacs bug Tracking System @ 2009-01-27 21:25 UTC (permalink / raw
To: Chong Yidong
[-- Attachment #1: Type: text/plain, Size: 914 bytes --]
Your message dated Tue, 27 Jan 2009 16:17:52 -0500
with message-id <87zlhcv473.fsf@cyd.mit.edu>
and subject line Re: 23.0.60; `concat' with longer strings aborts Emacs ungracefully
has caused the Emacs bug report #1787,
regarding 23.0.60; `concat' with longer strings aborts Emacs ungracefully
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.)
--
1787: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1787
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems
[-- Attachment #2: Type: message/rfc822, Size: 5572 bytes --]
From: Markus Triska <markus.triska@gmx.at>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.60; `concat' with longer strings aborts Emacs ungracefully
Date: Mon, 5 Jan 2009 02:23:20 +0100 (CET)
Message-ID: <20090105012320.15DD9C24862@mt-computer.local>
On OSX and Ubuntu jaunty machines with 1 GB RAM, doing:
$ emacs -Q --eval "(let ((v \"x\")) (while t (setq v (concat v v))))"
aborts Emacs with the following backtrace:
(gdb) bt
#0 0x9010d3db in abort ()
#1 0x0013a561 in make_uninit_multibyte_string (nchars=-536870912, nbytes=-536870912) at alloc.c:2503
#2 0x0013a590 in make_uninit_string (length=-536870912) at alloc.c:2486
#3 0x00159210 in concat (nargs=2, args=0xbfffec90, target_type=Lisp_String, last_special=0) at fns.c:619
#4 0x00152c10 in Feval (form=41853805) at eval.c:2348
#5 0x00152cbc in Fsetq (args=41853797) at eval.c:551
#6 0x00152b58 in Feval (form=41853789) at eval.c:2322
#7 0x00152e34 in Fprogn (args=41853837) at eval.c:449
#8 0x00155199 in Fwhile (args=41853781) at eval.c:1111
#9 0x00152b58 in Feval (form=41853773) at eval.c:2322
#10 0x00152e34 in Fprogn (args=41853845) at eval.c:449
#11 0x001552a5 in Flet (args=41853765) at eval.c:1089
#12 0x00152b58 in Feval (form=41853733) at eval.c:2322
#13 0x00153621 in Ffuncall (nargs=2, args=0xbffff0b0) at eval.c:3050
#14 0x0018cb8b in Fbyte_code (bytestr=2175051, vector=2175068, maxdepth=10) at bytecode.c:678
#15 0x00152f2b in funcall_lambda (fun=2175020, nargs=1, arg_vector=0xbffff254) at eval.c:3231
#16 0x0015340e in Ffuncall (nargs=2, args=0xbffff250) at eval.c:3101
#17 0x0018cb8b in Fbyte_code (bytestr=2161403, vector=2161420, maxdepth=7) at bytecode.c:678
#18 0x00152f2b in funcall_lambda (fun=2161380, nargs=0, arg_vector=0xbffff3e4) at eval.c:3231
#19 0x0015340e in Ffuncall (nargs=1, args=0xbffff3e0) at eval.c:3101
#20 0x0018cb8b in Fbyte_code (bytestr=2158059, vector=2158076, maxdepth=6) at bytecode.c:678
#21 0x00152f2b in funcall_lambda (fun=2158036, nargs=0, arg_vector=0xbffff500) at eval.c:3231
#22 0x00153196 in apply_lambda (fun=2158036, args=58721289, eval_flag=1) at eval.c:3155
#23 0x001528e0 in Feval (form=35544669) at eval.c:2435
#24 0x000e3a9c in top_level_2 () at keyboard.c:1358
#25 0x00151798 in internal_condition_case (bfun=0xe3a80 <top_level_2>, handlers=58760953, hfun=0xea6ef <cmd_error>) at eval.c:1511
#26 0x000e3ae4 in top_level_1 () at keyboard.c:1366
#27 0x001513ea in internal_catch (tag=58757025, func=0xe3aa2 <top_level_1>, arg=58721289) at eval.c:1247
#28 0x000e37ff in command_loop () at keyboard.c:1321
#29 0x000e38cf in recursive_edit_1 () at keyboard.c:942
#30 0x000e3a17 in Frecursive_edit () at keyboard.c:1004
#31 0x000e282f in main (argc=4, argv=0xbffff97c) at emacs.c:1786
Lisp Backtrace:
"concat" (0xbfffec90)
"setq" (0xbfffede8)
"while" (0xbfffeed8)
"let" (0xbffff008)
"eval" (0xbffff0b4)
"command-line-1" (0xbffff254)
"command-line" (0xbffff3e4)
"normal-top-level" (0xbffff500)
To me, throwing an error seems to be much preferable in this case.
In GNU Emacs 23.0.60.1 (i386-apple-darwin8.11.1, GTK+ Version 2.12.9)
of 2008-12-25 on mt-computer.local
Windowing system distributor `The XFree86 Project, Inc', version 11.0.40400000
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: en_GB.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: nil
default-enable-multibyte-characters: t
[-- Attachment #3: Type: message/rfc822, Size: 1278 bytes --]
From: Chong Yidong <cyd@stupidchicken.com>
To: Markus Triska <markus.triska@gmx.at>
Cc: 1787-done@emacsbugs.donarmstrong.com
Subject: Re: 23.0.60; `concat' with longer strings aborts Emacs ungracefully
Date: Tue, 27 Jan 2009 16:17:52 -0500
Message-ID: <87zlhcv473.fsf@cyd.mit.edu>
> On OSX and Ubuntu jaunty machines with 1 GB RAM, doing:
>
> $ emacs -Q --eval "(let ((v \"x\")) (while t (setq v (concat v
> v))))"
>
> aborts Emacs
I've checked in a fix. Thanks.
^ permalink raw reply [flat|nested] 2+ messages in thread