GNU bug report logs - #32351
assq_no_quit: circular loop (default, line-number, line-number-current-line)

Previous Next

Package: emacs;

Reported by: Keith David Bershatsky <esq <at> lawlist.com>

Date: Fri, 3 Aug 2018 02:11:02 UTC

Severity: normal

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Keith David Bershatsky <esq <at> lawlist.com>
Subject: bug#32351: closed (Re: bug#32351: assq_no_quit: circular loop
 (default, line-number, line-number-current-line))
Date: Tue, 28 Aug 2018 19:20:02 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#32351: assq_no_quit: circular loop (default, line-number, line-number-current-line)

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 32351 <at> debbugs.gnu.org.

-- 
32351: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=32351
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Eli Zaretskii <eliz <at> gnu.org>
To: Keith David Bershatsky <esq <at> lawlist.com>
Cc: 32351-done <at> debbugs.gnu.org
Subject: Re: bug#32351: assq_no_quit: circular loop (default, line-number,
 line-number-current-line)
Date: Tue, 28 Aug 2018 22:19:19 +0300
> Date:  Tue, 28 Aug 2018 11:46:24 -0700
> From:  Keith David Bershatsky <esq <at> lawlist.com>
> Cc:  32351 <at> debbugs.gnu.org
> 
> The test case for Emacs -q (mentioned in Message #20 of this thread) now succeeds without entering an infinite loop on Emacs 26 built --with-ns.  Good job!

Thanks for testing, I'm therefore closing the bug.

[Message part 3 (message/rfc822, inline)]
From: Keith David Bershatsky <esq <at> lawlist.com>
To: Emacs Bug Reports <bug-gnu-emacs <at> gnu.org>
Subject: assq_no_quit: circular loop (default, line-number,
 line-number-current-line)
Date: Thu, 02 Aug 2018 19:10:12 -0700
I apologize in advance for "not yet" having a concise recipe from Emacs -Q.  I can work on creating a recipe in the coming days/weeks/months.  I am able to produce this reliably in Emacs master branch, using a full user configuration.  Here are the relevant lines from LIST to the assq_no_quit function.

(line-number-current-line . [face unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified line-number unspecified unspecified])

(line-number . [face unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified unspecified (shadow default) unspecified unspecified])

(default . [face "Courier" "nil" normal 180 normal normal nil nil "white" "black" nil nil nil nil #<font-object "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1"> nil "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-fontset-auto1" unspecified]))

If I start/stop Emacs with the gdb, the KEY to assq_no_quit oscillates from the above three (3) faces.  Any ideas why this is a never ending loop?

The source code line numbers will be off because this is my working copy for developing feature requests (crosshairs/multiple-fake-cursors).  According to the gdb printout, my custom modifications are not at issue here.  Maybe it has something do with "font-object" in the default face above?

Program received signal SIGTSTP, Stopped (user).
0x0000000100216c51 in assq_no_quit (key=XIL(0x7c80), list=XIL(0x11b813b63))
    at fns.c:1487
1487	  for (; ! NILP (list); list = XCDR (list))
(gdb) bt
#0  0x0000000100216c51 in assq_no_quit (key=XIL(0x7c80), list=XIL(0x11b813b63))
    at fns.c:1487
#1  0x000000010012c656 in lface_from_face_name_no_resolve (f=0x10308cbb0, 
    face_name=XIL(0x7c80), signal_p=false) at xfaces.c:1860
#2  0x000000010012c74f in get_lface_attributes_no_remap (f=0x10308cbb0, 
    face_name=XIL(0x7c80), attrs=0x7fff5fbebb30, signal_p=false)
    at xfaces.c:1902
#3  0x000000010012c956 in get_lface_attributes (w=0x10309da30, f=0x10308cbb0, 
    face_name=XIL(0x7c80), attrs=0x7fff5fbebb30, signal_p=false, 
    named_merge_points=0x7fff5fbebbd0) at xfaces.c:1952
#4  0x000000010012d3c9 in merge_named_face (w=0x10309da30, f=0x10308cbb0, 
    face_name=XIL(0x7c80), to=0x7fff5fbebc30, named_merge_points=0x7fff5fbebbd0)
    at xfaces.c:2178
#5  0x0000000100138b28 in merge_faces (w=0x10309da30, face_name=XIL(0x7c80), 
    face_id=0, base_face_id=0) at xfaces.c:6352
#6  0x000000010007a8ba in maybe_produce_line_number (it=0x7fff5fbf5880)
    at xdisp.c:23690
#7  0x000000010005067f in move_it_in_display_line_to (it=0x7fff5fbf5880, 
    to_charpos=11104, to_x=-1, op=MOVE_TO_POS) at xdisp.c:11166
#8  0x00000001000546c4 in move_it_to (it=0x7fff5fbf5880, to_charpos=11104, 
    to_x=-1, to_y=-1, to_vpos=-1, op=8) at xdisp.c:11976
#9  0x00000001000550b4 in move_it_vertically_backward (it=0x7fff5fbf80d0, 
    dy=962) at xdisp.c:12170
#10 0x000000010006ba00 in redisplay_window (window=XIL(0x10309da35), 
    just_this_one_p=false) at xdisp.c:19855
#11 0x0000000100062ba3 in redisplay_window_0 (window=XIL(0x10309da35))
    at xdisp.c:17440
#12 0x0000000100208b85 in internal_condition_case_1 (
    bfun=0x100062b64 <redisplay_window_0>, arg=XIL(0x10309da35), 
    handlers=XIL(0x10181fe43), hfun=0x100062b2c <redisplay_window_error>)
    at eval.c:1373
#13 0x0000000100062b02 in redisplay_windows (window=XIL(0x10309da35))
    at xdisp.c:17420
#14 0x0000000100062abd in redisplay_windows (window=XIL(0x11d4d4d15))
    at xdisp.c:17414
#15 0x00000001000614ba in redisplay_internal () at xdisp.c:16889
#16 0x000000010005b887 in echo_area_display (update_frame_p=true)
    at xdisp.c:14107
* * *



This bug report was last modified 6 years and 266 days ago.

Previous Next


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