GNU bug report logs - #11874
24.1.50; Infloop in Info

Previous Next

Package: emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Sat, 7 Jul 2012 16:19:02 UTC

Severity: normal

Found in version 24.1.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11874 in the body.
You can then email your comments to 11874 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#11874; Package emacs. (Sat, 07 Jul 2012 16:19:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Eli Zaretskii <eliz <at> gnu.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 07 Jul 2012 16:19:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.1.50; Infloop in Info
Date: Sat, 07 Jul 2012 19:12:42 +0300
This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgement at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

Today's trunk infloops when I visit any Info manual.  To reproduce

  cd src
  ./emacs -Q
  C-u C-h i ../info/emacs.info RET

Attaching a debugger reveals the backtrace shown below.  Typing
"finish" repeatedly until it hangs again shows that it infloops in
Info-toc-build.  On GNU/Linux, if I type Ctrl-C into the debugger when
Emacs infloops, I can interrupt the loop, and Emacs becomes responsive
again.

I see the same infloop on GNU/Linux (on a TTY) and also on MS-Windows
in both GUI and TTY sessions.  The problem exists at least since
yesterday, because I also saw it before updating from trunk today.

Here's the backtrace obtained on an x86_64 GNU/Linux host:

#0  0x000000000053ca6e in multibyte_chars_in_text (
    ptr=0x7fdf12487ed3 "n list.\n\n   If `completion-auto-help' is set to `nil', the completion commands\nnever display the completion list buffer; you must type `?'  to display\nthe list.  If the value is `lazy', Emacs only sho"...,
    nbytes=298563) at character.c:538
#1  0x0000000000635ede in byte_char_debug_check (b=0x2c6a730, charpos=298564,
    bytepos=298564) at marker.c:53
#2  0x0000000000637b22 in buf_bytepos_to_charpos (b=0x2c6a730, bytepos=298564)
    at marker.c:333
#3  0x0000000000665794 in search_buffer (string=18984305, pos=298014,
    pos_byte=298564, lim=299248, lim_byte=299248, n=1, RE=1, trt=20254853,
    inverse_trt=20445477, posix=0) at search.c:1226
#4  0x0000000000664c7c in search_command (string=18984305, bound=1196992,
    noerror=15309490, count=15309442, direction=1, RE=1, posix=0)
    at search.c:996
#5  0x0000000000668e70 in Fre_search_forward (regexp=18984305, bound=1196992,
    noerror=15309490, count=15309442) at search.c:2164
#6  0x00000000006bb8e4 in Ffuncall (nargs=4, args=0x7fffb4bf1e28)
    at eval.c:2831
#7  0x000000000072bfdb in exec_byte_code (bytestr=15413281, vector=20359909,
    maxdepth=24, args_template=15309442, nargs=0, args=0x0) at bytecode.c:783
#8  0x00000000006bc7c3 in funcall_lambda (fun=20643461, nargs=1,
    arg_vector=0x136aae5) at eval.c:3052
#9  0x00000000006bbbb4 in Ffuncall (nargs=2, args=0x7fffb4bf2318)
    at eval.c:2869
#10 0x000000000072bfdb in exec_byte_code (bytestr=18945201, vector=20360349,
    maxdepth=20, args_template=15309442, nargs=0, args=0x0) at bytecode.c:783
#11 0x00000000006bc7c3 in funcall_lambda (fun=20643517, nargs=1,
    arg_vector=0x136ac9d) at eval.c:3052
#12 0x00000000006bbbb4 in Ffuncall (nargs=2, args=0x7fffb4bf27f8)
    at eval.c:2869
#13 0x000000000072bfdb in exec_byte_code (bytestr=18061809, vector=21123861,
    maxdepth=60, args_template=15309442, nargs=0, args=0x0) at bytecode.c:783
#14 0x00000000006bc7c3 in funcall_lambda (fun=21124165, nargs=0,
    arg_vector=0x1425315) at eval.c:3052
#15 0x00000000006bbbb4 in Ffuncall (nargs=1, args=0x7fffb4bf2d40)
    at eval.c:2869
#16 0x000000000072bfdb in exec_byte_code (bytestr=18063105, vector=18083493,
    maxdepth=52, args_template=15309442, nargs=0, args=0x0) at bytecode.c:783
#17 0x00000000006bc7c3 in funcall_lambda (fun=21124565, nargs=0,
    arg_vector=0x113eea5) at eval.c:3052
#18 0x00000000006bbbb4 in Ffuncall (nargs=1, args=0x7fffb4bf3248)
    at eval.c:2869
#19 0x000000000072bfdb in exec_byte_code (bytestr=18021025, vector=20626765,
    maxdepth=24, args_template=15309442, nargs=0, args=0x0) at bytecode.c:783
#20 0x00000000006bc7c3 in funcall_lambda (fun=20627077, nargs=0,
    arg_vector=0x13abd4d) at eval.c:3052
#21 0x00000000006bbbb4 in Ffuncall (nargs=1, args=0x7fffb4bf3738)
    at eval.c:2869
#22 0x000000000072bfdb in exec_byte_code (bytestr=17997185, vector=20614165,
    maxdepth=24, args_template=15309442, nargs=0, args=0x0) at bytecode.c:783
#23 0x00000000006bc7c3 in funcall_lambda (fun=20614709, nargs=3,
    arg_vector=0x13a8c15) at eval.c:3052
#24 0x00000000006bbbb4 in Ffuncall (nargs=4, args=0x7fffb4bf3c28)
    at eval.c:2869
#25 0x000000000072bfdb in exec_byte_code (bytestr=17982993, vector=20605957,
    maxdepth=16, args_template=15309442, nargs=0, args=0x0) at bytecode.c:783
#26 0x00000000006bc7c3 in funcall_lambda (fun=20602365, nargs=2,
    arg_vector=0x13a6c05) at eval.c:3052
#27 0x00000000006bbbb4 in Ffuncall (nargs=3, args=0x7fffb4bf4108)
    at eval.c:2869
#28 0x000000000072bfdb in exec_byte_code (bytestr=18031921, vector=20630677,
    maxdepth=24, args_template=15309442, nargs=0, args=0x0) at bytecode.c:783
#29 0x00000000006bc7c3 in funcall_lambda (fun=20630989, nargs=1,
    arg_vector=0x13acc95) at eval.c:3052
#30 0x00000000006bbbb4 in Ffuncall (nargs=2, args=0x7fffb4bf45f8)
    at eval.c:2869
#31 0x000000000072bfdb in exec_byte_code (bytestr=17962721, vector=20601573,
    maxdepth=16, args_template=15309442, nargs=0, args=0x0) at bytecode.c:783
#32 0x00000000006bc7c3 in funcall_lambda (fun=20601693, nargs=2,
    arg_vector=0x13a5ae5) at eval.c:3052
#33 0x00000000006bbbb4 in Ffuncall (nargs=3, args=0x7fffb4bf4ad8)
    at eval.c:2869
#34 0x000000000072bfdb in exec_byte_code (bytestr=17961745, vector=20598325,
#35 0x00000000006bc7c3 in funcall_lambda (fun=20581869, nargs=2,
    arg_vector=0x13a4e35) at eval.c:3052
#36 0x00000000006bbbb4 in Ffuncall (nargs=3, args=0x7fffb4bf4fb0)
    at eval.c:2869
#37 0x00000000006ba30e in Fapply (nargs=2, args=0x7fffb4bf50a0) at eval.c:2324
#38 0x00000000006ba99a in apply1 (fn=18744290, arg=17976182) at eval.c:2562
#39 0x00000000006b1ae1 in Fcall_interactively (function=18744290,
    record_flag=15309442, keys=15344501) at callint.c:378
#40 0x00000000006bb860 in Ffuncall (nargs=4, args=0x7fffb4bf53d0)
    at eval.c:2827
#41 0x00000000006baaae in call3 (fn=15448146, arg1=18744290, arg2=15309442,
    arg3=15309442) at eval.c:2619
#42 0x00000000005fd869 in Fcommand_execute (cmd=18744290,
    record_flag=15309442, keys=15309442, special=15309442) at keyboard.c:10336
#43 0x00000000005e044c in command_loop_1 () at keyboard.c:1569
#44 0x00000000006b6a8b in internal_condition_case (
    bfun=0x5df238 <command_loop_1>, handlers=15361106,
    hfun=0x5de8f4 <cmd_error>) at eval.c:1332
#45 0x00000000005dedf7 in command_loop_2 (ignore=15309442) at keyboard.c:1152
#46 0x00000000006b6348 in internal_catch (tag=15356978,
    func=0x5dedd1 <command_loop_2>, arg=15309442) at eval.c:1089
#47 0x00000000005dedaa in command_loop () at keyboard.c:1131
#48 0x00000000005de140 in recursive_edit_1 () at keyboard.c:752
#49 0x00000000005de51b in Frecursive_edit () at keyboard.c:816
#50 0x00000000005dbca4 in main (argc=2, argv=0x7fffb4bf5dc8) at emacs.c:1693

Lisp Backtrace:
"re-search-forward" (0xb4bf1e30)
"Info-toc-build" (0xb4bf2320)
"Info-toc-nodes" (0xb4bf2800)
"Info-breadcrumbs" (0xb4bf2d48)
"Info-fontify-node" (0xb4bf3250)
"Info-select-node" (0xb4bf3740)
"Info-find-node-2" (0xb4bf3c30)
"Info-find-node" (0xb4bf4110)
"Info-goto-node" (0xb4bf4600)
"info-setup" (0xb4bf4ae0)
"info" (0xb4bf4fb8)
"call-interactively" (0xb4bf53d8)

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'.
For information about debugging Emacs, please read the file
/home/e/eliz/bzr/emacs/trunk/etc/DEBUG.


In GNU Emacs 24.1.50.4 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2012-07-07 on fencepost.gnu.org
Bzr revision: 108937 bastien1 <at> free.fr-20120707143747-988mrp1fb40mvtmf
Configured using:
 `configure '--enable-asserts' '--enable-checking' '--with-gif=no'
 '--with-tiff=no' 'CFLAGS=-O0 -ggdb -g3 -DGLYPH_DEBUG=1''

Important settings:
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
ESC [ > 0 ; 1 3 6 ; 0 c ESC x r e p o r t - e m TAB
RET

Recent messages:
("./src/emacs")
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dynamic-setting font-render-setting move-toolbar
gtk x-toolkit x multi-tty emacs)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#11874; Package emacs. (Tue, 10 Jul 2012 00:41:01 GMT) Full text and rfc822 format available.

Message #8 received at 11874 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11874 <at> debbugs.gnu.org
Subject: Re: bug#11874: 24.1.50; Infloop in Info
Date: Mon, 09 Jul 2012 20:35:39 -0400
Eli Zaretskii wrote:

> Today's trunk infloops when I visit any Info manual.  To reproduce
>
>   cd src
>   ./emacs -Q
>   C-u C-h i ../info/emacs.info RET
>
> Attaching a debugger reveals the backtrace shown below.  Typing
> "finish" repeatedly until it hangs again shows that it infloops in
> Info-toc-build.  On GNU/Linux, if I type Ctrl-C into the debugger when
> Emacs infloops, I can interrupt the loop, and Emacs becomes responsive
> again.
>
> I see the same infloop on GNU/Linux (on a TTY) and also on MS-Windows

No such problem for me with current trunk on a GNU/Linux TTY.
Are you still seeing it?




Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Tue, 10 Jul 2012 16:38:02 GMT) Full text and rfc822 format available.

Notification sent to Eli Zaretskii <eliz <at> gnu.org>:
bug acknowledged by developer. (Tue, 10 Jul 2012 16:38:02 GMT) Full text and rfc822 format available.

Message #13 received at 11874-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 11874-done <at> debbugs.gnu.org
Subject: Re: bug#11874: 24.1.50; Infloop in Info
Date: Tue, 10 Jul 2012 19:31:41 +0300
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: 11874 <at> debbugs.gnu.org
> Date: Mon, 09 Jul 2012 20:35:39 -0400
> 
> Eli Zaretskii wrote:
> 
> > Today's trunk infloops when I visit any Info manual.  To reproduce
> >
> >   cd src
> >   ./emacs -Q
> >   C-u C-h i ../info/emacs.info RET
> >
> > Attaching a debugger reveals the backtrace shown below.  Typing
> > "finish" repeatedly until it hangs again shows that it infloops in
> > Info-toc-build.  On GNU/Linux, if I type Ctrl-C into the debugger when
> > Emacs infloops, I can interrupt the loop, and Emacs becomes responsive
> > again.
> >
> > I see the same infloop on GNU/Linux (on a TTY) and also on MS-Windows
> 
> No such problem for me with current trunk on a GNU/Linux TTY.
> Are you still seeing it?

No, not today.  It seems to be fixed.  Closing.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 08 Aug 2012 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 13 years and 11 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.