emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#28710: closed (27.0.50; eassert failure in maybe_p


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#28710: closed (27.0.50; eassert failure in maybe_produce_line_number)
Date: Tue, 10 Oct 2017 06:22:01 +0000

Your message dated Tue, 10 Oct 2017 09:21:06 +0300
with message-id <address@hidden>
and subject line Re: bug#28710: 27.0.50; eassert failure in 
maybe_produce_line_number
has caused the debbugs.gnu.org bug report #28710,
regarding 27.0.50; eassert failure in maybe_produce_line_number
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
28710: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28710
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 27.0.50; eassert failure in maybe_produce_line_number Date: Wed, 04 Oct 2017 16:31:33 -0600
I can so far only produce this with magit[1], but I've attached the output
of "bt full" below.

1. Open up a diff in magit (e.g., M-x magit-status then RET on the first
line).
2. Press RET on an added line.
3. In the opened buffer, do M-: (setq display-line-numbers t)
4. C-x b RET
5. Press RET on the line again.

If I use (e)debug to try and trace the function call, then for whatever
reason it doesn't crash at step 5, but a call to `list-buffers' will
then crash. It also doesn't crash if I use (call-interactively
#'magit-diff-visit-file) rather than hitting RET, even though RET is
bound to `magit-diff-visit-file'.

Footnotes:

[1] https://github.com/magit/magit

Attachment: backtrace-orig
Description: bt full

In GNU Emacs 27.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.22.21)
 of 2017-10-04 built on lylat
Repository revision: 92045f4546b9708dc9f69954799d211c1f56ff1e
Windowing system distributor 'The X.Org Foundation', version 11.0.11903000
System Description:     Debian GNU/Linux testing (buster)

Configured using:
 'configure --enable-checking=yes,glyphs --enable-check-lisp-object-type
 'CFLAGS=-O0 -g3''

--- End Message ---
--- Begin Message --- Subject: Re: bug#28710: 27.0.50; eassert failure in maybe_produce_line_number Date: Tue, 10 Oct 2017 09:21:06 +0300
> From: Alex <address@hidden>
> Cc: address@hidden
> Date: Mon, 09 Oct 2017 13:36:41 -0600
> 
> Thread 1 "emacs" hit Hardware watchpoint 4: -location $2->redisplay
> 
> Old value = false
> New value = true
> fset_redisplay (f=0x15cac30 <bss_sbrk_buffer+8062480>) at xdisp.c:600
> 600   }
> #0  0x000000000043eddc in fset_redisplay (f=0x15cac30 
> <bss_sbrk_buffer+8062480>) at xdisp.c:600
> #1  0x000000000057abb6 in xg_update_scrollbar_pos (f=0x15cac30 
> <bss_sbrk_buffer+8062480>, scrollbar_id=0, top=0, left=736, width=16, 
> height=612) at gtkutil.c:3942
> #2  0x0000000000547fd9 in XTset_vertical_scroll_bar (w=0x15cbc30 
> <bss_sbrk_buffer+8066576>, portion=1228, whole=8237, position=0) at 
> xterm.c:6809
> #3  0x00000000004728d9 in set_vertical_scroll_bar (w=0x15cbc30 
> <bss_sbrk_buffer+8066576>) at xdisp.c:16372
> #4  0x0000000000476f90 in redisplay_window (window=XIL(0x15cbc35), 
> just_this_one_p=false) at xdisp.c:17527

Thanks, this is what I suspected: the difference between our systems
is that your Emacs is built with GTK, and moving the thumb of the GTK
scroll bar marks the frame garbaged, which also sets its redisplay
flag.

So this mystery is now solved, and we can close the bug.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]