unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#1787: 23.0.60; `concat' with longer strings aborts Emacs ungracefully
@ 2009-01-05  1:23 ` Markus Triska
  2009-01-27 21:25   ` bug#1787: marked as done (23.0.60; `concat' with longer strings aborts Emacs ungracefully ) Emacs bug Tracking System
  0 siblings, 1 reply; 2+ messages in thread
From: Markus Triska @ 2009-01-05  1:23 UTC (permalink / raw)
  To: emacs-pretest-bug


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






^ permalink raw reply	[flat|nested] 2+ messages in thread

* 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

end of thread, other threads:[~2009-01-27 21:25 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <87zlhcv473.fsf@cyd.mit.edu>
2009-01-05  1:23 ` bug#1787: 23.0.60; `concat' with longer strings aborts Emacs ungracefully Markus Triska
2009-01-27 21:25   ` bug#1787: marked as done (23.0.60; `concat' with longer strings aborts Emacs ungracefully ) 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).