all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Chris Mears <chris@cmears.id.au>
Cc: emacs-devel@gnu.org
Subject: Re: Problem with large buffers
Date: Sat, 23 Jul 2005 10:05:43 +1000	[thread overview]
Message-ID: <m3irz2mlns.fsf@loki.cmears.id.au> (raw)
In-Reply-To: <E1Dw6Me-00031J-5B@fencepost.gnu.org> (Richard M. Stallman's message of "Fri, 22 Jul 2005 18:51:32 -0400")

"Richard M. Stallman" <rms@gnu.org> writes:

>     Emacs highlights the first "world!" that is about to replace, then in
>     the echo area I see:
>
>       "Error in menu-bar-update-hook: (error Variable binding depth exceeds
>        max-specpdl-size)"
>
> Can you provide a precise way to reproduce this problem?
> Once able to reproduce it, I think we could fix it quickly.

This reproduces the problem for me:

emacs -q -nw '--eval=(progn (dotimes (i 60000) (insert "Hello world!\n"))
    (beginning-of-buffer) (replace-regexp "w.*" ""))'

> You could also try putting a breakpoint at this call to Fsignal
[...]
> You could then use the GDB commands backtrace and xbacktrace,
> and send us the output.

Here is the output of xbacktrace:

(gdb) xbacktrace
"perform-replace"
"replace-regexp"
"progn"
"eval"
"command-line-1"
"command-line"
"normal-top-level"

And this is backtrace's output:

#0  grow_specpdl () at eval.c:3089
#1  0x0813ba4d in specbind (symbol=137383713, value=2147483640) at
    #eval.c:3108
#2  0x08128ef2 in inhibit_garbage_collection () at alloc.c:4662
#3  0x08125f8a in truncate_undo_list (b=0x8301490) at undo.c:324
#4  0x08129ccf in Fgarbage_collect () at alloc.c:4712
#5  0x0813cc45 in Ffuncall (nargs=2, args=0xbffc6990) at eval.c:2798
#6  0x0813dbcc in call1 (fn=137810081, arg1=24472856) at eval.c:2652
#7  0x08126053 in truncate_undo_list (b=0x82fdc80) at undo.c:384
#8  0x08129ccf in Fgarbage_collect () at alloc.c:4712
#9  0x0813cc45 in Ffuncall (nargs=2, args=0xbffc6b70) at eval.c:2798
#10 0x0813dbcc in call1 (fn=137810081, arg1=24472856) at eval.c:2652
#11 0x08126053 in truncate_undo_list (b=0x82fdc80) at undo.c:384
#12 0x08129ccf in Fgarbage_collect () at alloc.c:4712
#13 0x0813cc45 in Ffuncall (nargs=2, args=0xbffc6d50) at eval.c:2798
#14 0x0813dbcc in call1 (fn=137810081, arg1=24472856) at eval.c:2652
#15 0x08126053 in truncate_undo_list (b=0x82fdc80) at undo.c:384
#16 0x08129ccf in Fgarbage_collect () at alloc.c:4712
#17 0x0813cc45 in Ffuncall (nargs=2, args=0xbffc6f30) at eval.c:2798
#18 0x0813dbcc in call1 (fn=137810081, arg1=24472856) at eval.c:2652
#19 0x08126053 in truncate_undo_list (b=0x82fdc80) at undo.c:384

[the above 4 functions repeat]

#1905 0x0813cc45 in Ffuncall (nargs=2, args=0xbfffe430) at eval.c:2798
#1906 0x0813dbcc in call1 (fn=137810081, arg1=24472856) at eval.c:2652
#1907 0x08126053 in truncate_undo_list (b=0x82fdc80) at undo.c:384
#1908 0x08129ccf in Fgarbage_collect () at alloc.c:4712
#1909 0x0816637f in Fbyte_code (bytestr=461752, vector=130,
    #maxdepth=-1073748596) at bytecode.c:724
#1910 0x0813c89f in funcall_lambda (fun=136903476, nargs=9,
    #arg_vector=0xbfffe704) at eval.c:3047
#1911 0x0813cbfe in Ffuncall (nargs=10, args=0xbfffe700) at eval.c:2915
#1912 0x08166003 in Fbyte_code (bytestr=137557665, vector=9,
    #maxdepth=-1073748224) at bytecode.c:689
#1913 0x0813c89f in funcall_lambda (fun=136889100, nargs=2,
    #arg_vector=0xbfffe7f0) at eval.c:3047
#1914 0x0813c9da in apply_lambda (fun=136889100, args=140231371,
    #eval_flag=1) at eval.c:2969
#1915 0x0813c19a in Feval (form=136889100) at eval.c:2261
#1916 0x0813c657 in Fprogn (args=1000) at eval.c:432
#1917 0x0813c46c in Feval (form=137023612) at eval.c:2150
#1918 0x0813cd81 in Ffuncall (nargs=2, args=0xbfffea94) at eval.c:2863
#1919 0x08166003 in Fbyte_code (bytestr=137306129, vector=1,
    #maxdepth=-1073747312) at bytecode.c:689
#1920 0x0813c89f in funcall_lambda (fun=136825652, nargs=1,
    #arg_vector=0xbfffebe4) at eval.c:3047
#1921 0x0813cbfe in Ffuncall (nargs=2, args=0xbfffebe0) at eval.c:2915
#1922 0x08166003 in Fbyte_code (bytestr=137439209, vector=1,
    #maxdepth=-1073746976) at bytecode.c:689
#1923 0x0813c89f in funcall_lambda (fun=136809412, nargs=0,
    #arg_vector=0xbfffed24) at eval.c:3047
#1924 0x0813cbfe in Ffuncall (nargs=1, args=0xbfffed20) at eval.c:2915
#1925 0x08166003 in Fbyte_code (bytestr=140053171, vector=0,
    #maxdepth=-1073746656) at bytecode.c:689
#1926 0x0813c89f in funcall_lambda (fun=136804308, nargs=0,
    #arg_vector=0xbfffee00) at eval.c:3047
#1927 0x0813c9da in apply_lambda (fun=136804308, args=137306129,
    #eval_flag=1) at eval.c:2969
#1928 0x0813c19a in Feval (form=136804308) at eval.c:2261
#1929 0x080df4d9 in top_level_2 () at keyboard.c:1327
#1930 0x0813b15a in internal_condition_case (bfun=0x80df4c8
    #<top_level_2>, handlers=137367121, 
    hfun=0x80e4aec <cmd_error>) at eval.c:1452
#1931 0x080df505 in top_level_1 () at keyboard.c:1335
#1932 0x0813b069 in internal_catch (tag=1000, func=0x80df4dc
    #<top_level_1>, arg=137306129) at eval.c:1211
#1933 0x080df2ab in command_loop () at keyboard.c:1292
#1934 0x080df363 in recursive_edit_1 () at keyboard.c:990
#1935 0x080df45e in Frecursive_edit () at keyboard.c:1051
#1936 0x080de7e5 in main (argc=4, argv=0xbffff4b4) at emacs.c:1782

  reply	other threads:[~2005-07-23  0:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-22  4:56 Problem with large buffers Chris Mears
2005-07-22 11:13 ` Mathias Dahl
2005-07-22 11:53 ` Chris Mears
2005-07-22 18:12   ` Juri Linkov
2005-07-22 22:51 ` Richard M. Stallman
2005-07-23  0:05   ` Chris Mears [this message]
2005-07-24  0:00     ` Richard M. Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3irz2mlns.fsf@loki.cmears.id.au \
    --to=chris@cmears.id.au \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.