* bug#35273: "Marker does not point anywhere" when reading next article
@ 2019-04-14 13:42 Leah Neukirchen
2019-04-14 16:31 ` Basil L. Contovounesios
0 siblings, 1 reply; 18+ messages in thread
From: Leah Neukirchen @ 2019-04-14 13:42 UTC (permalink / raw
To: 35273
Hi,
On Gnus 5.13/Emacs 26.2 (and 26.1), if I hover with the mouse a link
in Article view (such that it shows the tooltip "Follow the link"),
and press SPC to read the next article, the message "Marker does not
point anywhere" displays repeatedly, until the mouse is moved.
This sounds like bug#30519 but it's still in 26.2...
Gnus v5.13
GNU Emacs 26.2 (build 1, x86_64-unknown-linux-gnu, X toolkit)
of 2019-04-12
200 news.gmane.org InterNetNews NNRP server INN 2.6.1 ready (posting ok)
100 Legal commands
ARTICLE [message-ID|number]
AUTHINFO USER name|PASS password|SASL mechanism [initial-response]|GENERIC program [argument ...]
BODY [message-ID|number]
CAPABILITIES [keyword]
COMPRESS DEFLATE
DATE
GROUP newsgroup
HDR header [message-ID|range]
HEAD [message-ID|number]
HELP
IHAVE message-ID
LAST
LIST [ACTIVE [wildmat]|ACTIVE.TIMES [wildmat]|COUNTS [wildmat]|DISTRIB.PATS|DISTRIBUTIONS|HEADERS [MSGID|RANGE]|MODERATORS|MOTD|NEWSGROUPS [wildmat]|OVERVIEW.FMT|SUBSCRIPTIONS [wildmat]]
LISTGROUP [newsgroup [range]]
MODE READER
NEWGROUPS [yy]yymmdd hhmmss [GMT]
NEWNEWS wildmat [yy]yymmdd hhmmss [GMT]
NEXT
OVER [range]
POST
QUIT
STARTTLS
STAT [message-ID|number]
XGTITLE [wildmat]
XHDR header [message-ID|range]
XOVER [range]
XPAT header message-ID|range pattern [pattern ...]
Report problems to <usenet@blaine.gmane.org>.
.
382 Begin TLS negotiation now
100 Legal commands
ARTICLE [message-ID|number]
AUTHINFO USER name|PASS password|SASL mechanism [initial-response]|GENERIC program [argument ...]
BODY [message-ID|number]
CAPABILITIES [keyword]
COMPRESS DEFLATE
DATE
GROUP newsgroup
HDR header [message-ID|range]
HEAD [message-ID|number]
HELP
IHAVE message-ID
LAST
LIST [ACTIVE [wildmat]|ACTIVE.TIMES [wildmat]|COUNTS [wildmat]|DISTRIB.PATS|DISTRIBUTIONS|HEADERS [MSGID|RANGE]|MODERATORS|MOTD|NEWSGROUPS [wildmat]|OVERVIEW.FMT|SUBSCRIPTIONS [wildmat]]
LISTGROUP [newsgroup [range]]
MODE READER
NEWGROUPS [yy]yymmdd hhmmss [GMT]
NEWNEWS wildmat [yy]yymmdd hhmmss [GMT]
NEXT
OVER [range]
POST
QUIT
STARTTLS
STAT [message-ID|number]
XGTITLE [wildmat]
XHDR header [message-ID|range]
XOVER [range]
XPAT header message-ID|range pattern [pattern ...]
Report problems to <usenet@blaine.gmane.org>.
.
--
Leah Neukirchen <leah@vuxu.org> http://leahneukirchen.org/
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-14 13:42 bug#35273: "Marker does not point anywhere" when reading next article Leah Neukirchen
@ 2019-04-14 16:31 ` Basil L. Contovounesios
2019-04-14 21:19 ` Leah Neukirchen
0 siblings, 1 reply; 18+ messages in thread
From: Basil L. Contovounesios @ 2019-04-14 16:31 UTC (permalink / raw
To: Leah Neukirchen; +Cc: 35273
Leah Neukirchen <leah@vuxu.org> writes:
> On Gnus 5.13/Emacs 26.2 (and 26.1), if I hover with the mouse a link
> in Article view (such that it shows the tooltip "Follow the link"),
> and press SPC to read the next article, the message "Marker does not
> point anywhere" displays repeatedly, until the mouse is moved.
>
> This sounds like bug#30519 but it's still in 26.2...
FWIW, I just tried this on a build of latest master with the link in
your signature, and saw no such messages.
--
Basil
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-14 16:31 ` Basil L. Contovounesios
@ 2019-04-14 21:19 ` Leah Neukirchen
2019-04-16 12:38 ` Noam Postavsky
0 siblings, 1 reply; 18+ messages in thread
From: Leah Neukirchen @ 2019-04-14 21:19 UTC (permalink / raw
To: Basil L. Contovounesios; +Cc: 35273
"Basil L. Contovounesios" <contovob@tcd.ie> writes:
> Leah Neukirchen <leah@vuxu.org> writes:
>
>> On Gnus 5.13/Emacs 26.2 (and 26.1), if I hover with the mouse a link
>> in Article view (such that it shows the tooltip "Follow the link"),
>> and press SPC to read the next article, the message "Marker does not
>> point anywhere" displays repeatedly, until the mouse is moved.
>>
>> This sounds like bug#30519 but it's still in 26.2...
>
> FWIW, I just tried this on a build of latest master with the link in
> your signature, and saw no such messages.
Ok, the setup is more contrived as I now figured out (but it still
happens in HEAD):
- The mouse needs to hover over the link in such a way that it will
be on a link again after pressing SPC (this is easy to trigger on From:
and articles that fit on a screen)
- elscreen needs to be loaded and started
- elscreen needs at least two tabs(!), with a single tab it doesn't trigger
I'm unable to make any good backtrace of this happening, other
than simply
command-error-default-function
I hope this helps reproducing. If you have other ideas how I can
debug it myself, please tell me.
--
Leah Neukirchen <leah@vuxu.org> http://leah.zone
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-14 21:19 ` Leah Neukirchen
@ 2019-04-16 12:38 ` Noam Postavsky
2019-04-16 12:50 ` Leah Neukirchen
0 siblings, 1 reply; 18+ messages in thread
From: Noam Postavsky @ 2019-04-16 12:38 UTC (permalink / raw
To: Leah Neukirchen; +Cc: Basil L. Contovounesios, 35273
Leah Neukirchen <leah@vuxu.org> writes:
> If you have other ideas how I can debug it myself, please tell me.
If you can reproduce it reliably, setting (setq debug-on-signal t) just
before might help get a backtrace.
If that also doesn't work you could record the backtrace from a
signal-hook-function:
(defvar bug-35273-last-backtrace nil)
(defun bug-35273-record-backtrace (err data)
(when (and (eq err 'error)
(equal data '("Marker does not point anywhere")))
(setq bug-35273-last-backtrace
(backtrace-frames 'signal)))
(let ((signal-hook-function nil))
(signal err data)))
(setq signal-hook-function #'bug-35273-record-backtrace)
Or if you can run under gdb, just set a breakpoint in the C code where
that error is raised.
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-16 12:38 ` Noam Postavsky
@ 2019-04-16 12:50 ` Leah Neukirchen
2019-04-16 13:13 ` Noam Postavsky
0 siblings, 1 reply; 18+ messages in thread
From: Leah Neukirchen @ 2019-04-16 12:50 UTC (permalink / raw
To: Noam Postavsky; +Cc: Basil L. Contovounesios, 35273
Noam Postavsky <npostavs@gmail.com> writes:
> Leah Neukirchen <leah@vuxu.org> writes:
>
>> If you have other ideas how I can debug it myself, please tell me.
>
> If you can reproduce it reliably, setting (setq debug-on-signal t) just
> before might help get a backtrace.
>
> If that also doesn't work you could record the backtrace from a
> signal-hook-function:
>
> (defvar bug-35273-last-backtrace nil)
> (defun bug-35273-record-backtrace (err data)
> (when (and (eq err 'error)
> (equal data '("Marker does not point anywhere")))
> (setq bug-35273-last-backtrace
> (backtrace-frames 'signal)))
> (let ((signal-hook-function nil))
> (signal err data)))
> (setq signal-hook-function #'bug-35273-record-backtrace)
These do not work for some reason...
> Or if you can run under gdb, just set a breakpoint in the C code where
> that error is raised.
On 27.0.50 (05d53d888):
Breakpoint 1, marker_position (marker=0x555557d6feb5) at marker.c:680
680 error ("Marker does not point anywhere");
(gdb) bt
#0 marker_position (marker=0x555557d6feb5) at marker.c:680
#1 0x000055555567935e in mouse_face_overlay_overlaps (overlay=0x555557d6ff15)
at lisp.h:2624
#2 0x00005555555d395f in note_mouse_highlight (f=f@entry=0x555556001d70,
x=<optimized out>, y=<optimized out>) at xdisp.c:31836
#3 0x0000555555633ee8 in XTframe_up_to_date (f=0x555556001d70) at xterm.c:1280
#4 0x00005555555c67de in redisplay_internal () at xdisp.c:14523
#5 0x00005555555c7dd5 in redisplay_preserve_echo_area (
from_where=from_where@entry=5) at xdisp.c:14759
#6 0x0000555555661902 in read_char (commandflag=commandflag@entry=1,
map=map@entry=0x555557807873, prev_event=0x0,
used_mouse_menu=used_mouse_menu@entry=0x7fffffffe05b,
end_time=end_time@entry=0x0) at keyboard.c:2474
#7 0x00005555556642a1 in read_key_sequence (
keybuf=keybuf@entry=0x7fffffffe170, prompt=prompt@entry=0x0,
dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false) at keyboard.c:9111
#8 0x0000555555665abc in command_loop_1 () at lisp.h:1064
#9 0x00005555556d4b6e in internal_condition_case (
bfun=bfun@entry=0x5555556658d0 <command_loop_1>,
handlers=handlers@entry=0x5010, hfun=hfun@entry=0x55555565ce40 <cmd_error>)
at eval.c:1352
#10 0x0000555555657b14 in command_loop_2 (ignore=ignore@entry=0x0)
at lisp.h:1064
#11 0x00005555556d4add in internal_catch (tag=tag@entry=0xc5d0,
func=func@entry=0x555555657af0 <command_loop_2>, arg=arg@entry=0x0)
at eval.c:1115
#12 0x0000555555657aab in command_loop () at lisp.h:1064
#13 0x000055555565ca36 in recursive_edit_1 () at keyboard.c:714
#14 0x000055555565cd69 in Frecursive_edit () at keyboard.c:786
#15 0x000055555558890e in main (argc=1, argv=0x7fffffffe538) at emacs.c:1963
(gdb) xbacktrace
"redisplay_internal (C function)" (0x0)
(gdb) p buf
$2 = (struct buffer *) 0x0
(gdb) p *m
$4 = {
header = {
size = 4611686018477740032
},
buffer = 0x0,
need_adjustment = false,
insertion_type = true,
next = 0x555557d6fe80,
charpos = 1,
bytepos = 1
}
hth,
--
Leah Neukirchen <leah@vuxu.org> http://leah.zone
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-16 12:50 ` Leah Neukirchen
@ 2019-04-16 13:13 ` Noam Postavsky
2019-04-16 13:21 ` Leah Neukirchen
0 siblings, 1 reply; 18+ messages in thread
From: Noam Postavsky @ 2019-04-16 13:13 UTC (permalink / raw
To: Leah Neukirchen; +Cc: Basil L. Contovounesios, 35273
Leah Neukirchen <leah@vuxu.org> writes:
>> If you can reproduce it reliably, setting (setq debug-on-signal t) just
>> before might help get a backtrace.
>>
>> If that also doesn't work you could record the backtrace from a
>> signal-hook-function:
>>
>> (defvar bug-35273-last-backtrace nil)
>> (defun bug-35273-record-backtrace (err data)[...]
>> (setq signal-hook-function #'bug-35273-record-backtrace)
>
> These do not work for some reason...
debug-on-signal doesn't work because the debugger is suppressed during
redisplay (to avoid recursion). I think the signal-hook-function might
have worked (though I forgot to tell you to check the value of
bug-35273-last-backtrace afterwards) but it would only have a single
frame of "redisplay" so it would be useless.
>> Or if you can run under gdb, just set a breakpoint in the C code where
>> that error is raised.
>
> On 27.0.50 (05d53d888):
>
> Breakpoint 1, marker_position (marker=0x555557d6feb5) at marker.c:680
> 680 error ("Marker does not point anywhere");
> (gdb) bt
> #0 marker_position (marker=0x555557d6feb5) at marker.c:680
> #1 0x000055555567935e in mouse_face_overlay_overlaps (overlay=0x555557d6ff15)
> at lisp.h:2624
> #2 0x00005555555d395f in note_mouse_highlight (f=f@entry=0x555556001d70,
> x=<optimized out>, y=<optimized out>) at xdisp.c:31836
The xdisp.c:31836 at revision 05d53d888 has
help_echo_pos = charpos;
And neither note_mouse_highlight nor mouse_face_overlay_overlaps call
marker_position, so I'm confused how we got there. note_mouse_highlight
does call Fmarker_position, but that one doesn't signal an error.
Maybe the debug info is messed up by optimization. Could you try
recompiling with CFLAGS='-O0 -g3'?
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-16 13:13 ` Noam Postavsky
@ 2019-04-16 13:21 ` Leah Neukirchen
2019-04-16 13:56 ` Noam Postavsky
0 siblings, 1 reply; 18+ messages in thread
From: Leah Neukirchen @ 2019-04-16 13:21 UTC (permalink / raw
To: Noam Postavsky; +Cc: Basil L. Contovounesios, 35273
Noam Postavsky <npostavs@gmail.com> writes:
> Leah Neukirchen <leah@vuxu.org> writes:
>
>>> If you can reproduce it reliably, setting (setq debug-on-signal t) just
>>> before might help get a backtrace.
>>>
>>> If that also doesn't work you could record the backtrace from a
>>> signal-hook-function:
>>>
>>> (defvar bug-35273-last-backtrace nil)
>>> (defun bug-35273-record-backtrace (err data)[...]
>
>>> (setq signal-hook-function #'bug-35273-record-backtrace)
>>
>> These do not work for some reason...
>
> debug-on-signal doesn't work because the debugger is suppressed during
> redisplay (to avoid recursion). I think the signal-hook-function might
> have worked (though I forgot to tell you to check the value of
> bug-35273-last-backtrace afterwards) but it would only have a single
> frame of "redisplay" so it would be useless.
(It was nil.)
>>> Or if you can run under gdb, just set a breakpoint in the C code where
>>> that error is raised.
>>
>> On 27.0.50 (05d53d888):
>>
>> Breakpoint 1, marker_position (marker=0x555557d6feb5) at marker.c:680
>> 680 error ("Marker does not point anywhere");
>> (gdb) bt
>> #0 marker_position (marker=0x555557d6feb5) at marker.c:680
>> #1 0x000055555567935e in mouse_face_overlay_overlaps (overlay=0x555557d6ff15)
>> at lisp.h:2624
>> #2 0x00005555555d395f in note_mouse_highlight (f=f@entry=0x555556001d70,
>> x=<optimized out>, y=<optimized out>) at xdisp.c:31836
>
> The xdisp.c:31836 at revision 05d53d888 has
>
> help_echo_pos = charpos;
>
> And neither note_mouse_highlight nor mouse_face_overlay_overlaps call
> marker_position, so I'm confused how we got there. note_mouse_highlight
> does call Fmarker_position, but that one doesn't signal an error.
>
> Maybe the debug info is messed up by optimization. Could you try
> recompiling with CFLAGS='-O0 -g3'?
(gdb) bt
#0 marker_position (marker=XIL(0x5555578a47c5)) at marker.c:680
#1 0x00005555556fc2dd in mouse_face_overlay_overlaps (
overlay=XIL(0x5555578a4825)) at buffer.c:3047
#2 0x0000555555606f5f in note_mouse_highlight (f=0x55555610dbf0, x=100, y=9)
at xdisp.c:31631
#3 0x0000555555691622 in XTframe_up_to_date (f=0x55555610dbf0) at xterm.c:1280
#4 0x00005555555d0714 in redisplay_internal () at xdisp.c:14523
#5 0x00005555555d0e38 in redisplay_preserve_echo_area (from_where=5)
at xdisp.c:14759
#6 0x00005555556d0c56 in read_char (commandflag=1, map=XIL(0x555557e1d043),
prev_event=XIL(0), used_mouse_menu=0x7fffffffdeb5, end_time=0x0)
at keyboard.c:2474
#7 0x00005555556de5dd in read_key_sequence (keybuf=0x7fffffffe0c0,
prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9111
#8 0x00005555556cddd9 in command_loop_1 () at keyboard.c:1350
#9 0x0000555555780598 in internal_condition_case (
bfun=0x5555556cd991 <command_loop_1>, handlers=XIL(0x5010),
hfun=0x5555556cd146 <cmd_error>) at eval.c:1352
#10 0x00005555556cd679 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091
#11 0x000055555577fe1a in internal_catch (tag=XIL(0xc5d0),
func=0x5555556cd64c <command_loop_2>, arg=XIL(0)) at eval.c:1115
#12 0x00005555556cd617 in command_loop () at keyboard.c:1070
#13 0x00005555556ccd15 in recursive_edit_1 () at keyboard.c:714
#14 0x00005555556cce99 in Frecursive_edit () at keyboard.c:786
#15 0x00005555556cacbc in main (argc=1, argv=0x7fffffffe538) at emacs.c:1963
Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb) up
#1 0x00005555556fc2dd in mouse_face_overlay_overlaps (
overlay=XIL(0x5555578a4825)) at buffer.c:3047
3047 ptrdiff_t start = OVERLAY_POSITION (OVERLAY_START (overlay));
(gdb) l
3042 `mouse-face' property overlapping OVERLAY. */
3043
3044 bool
3045 mouse_face_overlay_overlaps (Lisp_Object overlay)
3046 {
3047 ptrdiff_t start = OVERLAY_POSITION (OVERLAY_START (overlay));
3048 ptrdiff_t end = OVERLAY_POSITION (OVERLAY_END (overlay));
3049 ptrdiff_t n, i, size;
3050 Lisp_Object *v, tem;
3051 Lisp_Object vbuf[10];
(gdb) up
#2 0x0000555555606f5f in note_mouse_highlight (f=0x55555610dbf0, x=100, y=9)
at xdisp.c:31631
31631 && mouse_face_overlay_overlaps (hlinfo->mouse_face_overlay)))
(gdb) l
31626 if we enter the overlapping overlay, and then highlight
31627 only that. Skip the check when mouse-face highlighting
31628 is currently hidden to avoid Bug#30519. */
31629 || (!hlinfo->mouse_face_hidden
31630 && OVERLAYP (hlinfo->mouse_face_overlay)
31631 && mouse_face_overlay_overlaps (hlinfo->mouse_face_overlay)))
31632 {
31633 /* Find the highest priority overlay with a mouse-face. */
31634 Lisp_Object overlay = Qnil;
31635 for (i = noverlays - 1; i >= 0 && NILP (overlay); --i)
--
Leah Neukirchen <leah@vuxu.org> http://leah.zone
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-16 13:21 ` Leah Neukirchen
@ 2019-04-16 13:56 ` Noam Postavsky
2019-04-16 14:04 ` Leah Neukirchen
2019-04-16 15:02 ` Eli Zaretskii
0 siblings, 2 replies; 18+ messages in thread
From: Noam Postavsky @ 2019-04-16 13:56 UTC (permalink / raw
To: Leah Neukirchen; +Cc: Basil L. Contovounesios, 35273
Leah Neukirchen <leah@vuxu.org> writes:
> Noam Postavsky <npostavs@gmail.com> writes:
>
>> I think the signal-hook-function might have worked (though I forgot
>> to tell you to check the value of bug-35273-last-backtrace
>> afterwards) but it would only have a single frame of "redisplay" so
>> it would be useless.
>
> (It was nil.)
Oh, hmm. Maybe the backtrace doesn't have `signal' in that
context, so nothing is collected.
>> And neither note_mouse_highlight nor mouse_face_overlay_overlaps call
>> marker_position, so I'm confused how we got there. note_mouse_highlight
>> does call Fmarker_position, but that one doesn't signal an error.
>>
>> Maybe the debug info is messed up by optimization. Could you try
>> recompiling with CFLAGS='-O0 -g3'?
>
> (gdb) bt
> #0 marker_position (marker=XIL(0x5555578a47c5)) at marker.c:680
> #1 0x00005555556fc2dd in mouse_face_overlay_overlaps (
> overlay=XIL(0x5555578a4825)) at buffer.c:3047
> #2 0x0000555555606f5f in note_mouse_highlight (f=0x55555610dbf0, x=100, y=9)
> at xdisp.c:31631
> (gdb) up
> #1 0x00005555556fc2dd in mouse_face_overlay_overlaps (
> overlay=XIL(0x5555578a4825)) at buffer.c:3047
> 3047 ptrdiff_t start = OVERLAY_POSITION (OVERLAY_START (overlay));
> (gdb) l
> 3042 `mouse-face' property overlapping OVERLAY. */
> 3043
> 3044 bool
> 3045 mouse_face_overlay_overlaps (Lisp_Object overlay)
> 3046 {
> 3047 ptrdiff_t start = OVERLAY_POSITION (OVERLAY_START (overlay));
> 3048 ptrdiff_t end = OVERLAY_POSITION (OVERLAY_END (overlay));
Oh right, OVERLAY_POSITION calls marker_position. I think the patch
below should paper over the problem, but I'm not sure if it's the right
thing.
--- i/src/buffer.c
+++ w/src/buffer.c
@@ -3044,8 +3044,13 @@ overlays_in (EMACS_INT beg, EMACS_INT end, bool extend,
bool
mouse_face_overlay_overlaps (Lisp_Object overlay)
{
- ptrdiff_t start = OVERLAY_POSITION (OVERLAY_START (overlay));
- ptrdiff_t end = OVERLAY_POSITION (OVERLAY_END (overlay));
+ Lisp_Object start_pos = Fmarker_position (OVERLAY_START (overlay));
+ Lisp_Object end_pos = Fmarker_position (OVERLAY_END (overlay));
+ if (!(INTEGERP (start_pos) && INTEGERP (end_pos)))
+ return false;
+ intmax_t start, end;
+ integer_to_intmax (start_pos, &start);
+ integer_to_intmax (end_pos, &end);
ptrdiff_t n, i, size;
Lisp_Object *v, tem;
Lisp_Object vbuf[10];
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-16 13:56 ` Noam Postavsky
@ 2019-04-16 14:04 ` Leah Neukirchen
2019-04-16 15:02 ` Eli Zaretskii
1 sibling, 0 replies; 18+ messages in thread
From: Leah Neukirchen @ 2019-04-16 14:04 UTC (permalink / raw
To: Noam Postavsky; +Cc: Basil L. Contovounesios, 35273
Noam Postavsky <npostavs@gmail.com> writes:
>> (gdb) bt
>> #0 marker_position (marker=XIL(0x5555578a47c5)) at marker.c:680
>> #1 0x00005555556fc2dd in mouse_face_overlay_overlaps (
>> overlay=XIL(0x5555578a4825)) at buffer.c:3047
>> #2 0x0000555555606f5f in note_mouse_highlight (f=0x55555610dbf0, x=100, y=9)
>> at xdisp.c:31631
>
>> (gdb) up
>> #1 0x00005555556fc2dd in mouse_face_overlay_overlaps (
>> overlay=XIL(0x5555578a4825)) at buffer.c:3047
>> 3047 ptrdiff_t start = OVERLAY_POSITION (OVERLAY_START (overlay));
>> (gdb) l
>> 3042 `mouse-face' property overlapping OVERLAY. */
>> 3043
>> 3044 bool
>> 3045 mouse_face_overlay_overlaps (Lisp_Object overlay)
>> 3046 {
>> 3047 ptrdiff_t start = OVERLAY_POSITION (OVERLAY_START (overlay));
>> 3048 ptrdiff_t end = OVERLAY_POSITION (OVERLAY_END (overlay));
>
> Oh right, OVERLAY_POSITION calls marker_position. I think the patch
> below should paper over the problem, but I'm not sure if it's the right
> thing.
>
> --- i/src/buffer.c
> +++ w/src/buffer.c
> @@ -3044,8 +3044,13 @@ overlays_in (EMACS_INT beg, EMACS_INT end, bool extend,
> bool
> mouse_face_overlay_overlaps (Lisp_Object overlay)
> {
> - ptrdiff_t start = OVERLAY_POSITION (OVERLAY_START (overlay));
> - ptrdiff_t end = OVERLAY_POSITION (OVERLAY_END (overlay));
> + Lisp_Object start_pos = Fmarker_position (OVERLAY_START (overlay));
> + Lisp_Object end_pos = Fmarker_position (OVERLAY_END (overlay));
> + if (!(INTEGERP (start_pos) && INTEGERP (end_pos)))
> + return false;
> + intmax_t start, end;
> + integer_to_intmax (start_pos, &start);
> + integer_to_intmax (end_pos, &end);
> ptrdiff_t n, i, size;
> Lisp_Object *v, tem;
> Lisp_Object vbuf[10];
>
I cannot reproduce the error anymore after applying the patch.
Thanks,
--
Leah Neukirchen <leah@vuxu.org> http://leah.zone
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-16 13:56 ` Noam Postavsky
2019-04-16 14:04 ` Leah Neukirchen
@ 2019-04-16 15:02 ` Eli Zaretskii
2019-04-20 12:05 ` Noam Postavsky
1 sibling, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2019-04-16 15:02 UTC (permalink / raw
To: Noam Postavsky; +Cc: contovob, 35273, leah
> From: Noam Postavsky <npostavs@gmail.com>
> Date: Tue, 16 Apr 2019 09:56:36 -0400
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, 35273@debbugs.gnu.org
>
> Oh right, OVERLAY_POSITION calls marker_position. I think the patch
> below should paper over the problem, but I'm not sure if it's the right
> thing.
I think it would be better to try to understand how we got such an
overlay. Was it deleted, per chance?
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-16 15:02 ` Eli Zaretskii
@ 2019-04-20 12:05 ` Noam Postavsky
2019-04-20 13:44 ` Eli Zaretskii
0 siblings, 1 reply; 18+ messages in thread
From: Noam Postavsky @ 2019-04-20 12:05 UTC (permalink / raw
To: Eli Zaretskii; +Cc: contovob, 35273, leah
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Noam Postavsky <npostavs@gmail.com>
>> Date: Tue, 16 Apr 2019 09:56:36 -0400
>> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, 35273@debbugs.gnu.org
>>
>> Oh right, OVERLAY_POSITION calls marker_position. I think the patch
>> below should paper over the problem, but I'm not sure if it's the right
>> thing.
>
> I think it would be better to try to understand how we got such an
> overlay. Was it deleted, per chance?
I entirely agree with this, but how to check for that?
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-20 12:05 ` Noam Postavsky
@ 2019-04-20 13:44 ` Eli Zaretskii
2019-04-20 16:20 ` Eli Zaretskii
0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2019-04-20 13:44 UTC (permalink / raw
To: Noam Postavsky; +Cc: contovob, 35273, leah
> From: Noam Postavsky <npostavs@gmail.com>
> Cc: contovob@tcd.ie, 35273@debbugs.gnu.org, leah@vuxu.org
> Date: Sat, 20 Apr 2019 08:05:30 -0400
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Noam Postavsky <npostavs@gmail.com>
> >> Date: Tue, 16 Apr 2019 09:56:36 -0400
> >> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, 35273@debbugs.gnu.org
> >>
> >> Oh right, OVERLAY_POSITION calls marker_position. I think the patch
> >> below should paper over the problem, but I'm not sure if it's the right
> >> thing.
> >
> > I think it would be better to try to understand how we got such an
> > overlay. Was it deleted, per chance?
>
> I entirely agree with this, but how to check for that?
But a breakpoint in delete-overlay?
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-20 13:44 ` Eli Zaretskii
@ 2019-04-20 16:20 ` Eli Zaretskii
2019-04-27 16:17 ` Noam Postavsky
0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2019-04-20 16:20 UTC (permalink / raw
To: npostavs; +Cc: contovob, 35273, leah
> Date: Sat, 20 Apr 2019 16:44:04 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: contovob@tcd.ie, 35273@debbugs.gnu.org, leah@vuxu.org
>
> > > I think it would be better to try to understand how we got such an
> > > overlay. Was it deleted, per chance?
> >
> > I entirely agree with this, but how to check for that?
>
> But a breakpoint in delete-overlay?
Btw, does anyone understand how does elscreen affect this issue? Does
that package manipulate overlays or help-echo properties?
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-20 16:20 ` Eli Zaretskii
@ 2019-04-27 16:17 ` Noam Postavsky
2019-04-27 16:49 ` Eli Zaretskii
0 siblings, 1 reply; 18+ messages in thread
From: Noam Postavsky @ 2019-04-27 16:17 UTC (permalink / raw
To: Eli Zaretskii; +Cc: contovob, 35273, leah
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Sat, 20 Apr 2019 16:44:04 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: contovob@tcd.ie, 35273@debbugs.gnu.org, leah@vuxu.org
>>
>> > > I think it would be better to try to understand how we got such an
>> > > overlay. Was it deleted, per chance?
>> >
>> > I entirely agree with this, but how to check for that?
>>
>> But a breakpoint in delete-overlay?
I managed to reproduce (wasn't too hard actually). All the overlay
deletion seems to come from gnus. I got hits from erase-buffer (called
by gnus), gnus-kill-all-overlays, and gnus-cite-delete-overlays.
> Btw, does anyone understand how does elscreen affect this issue? Does
> that package manipulate overlays or help-echo properties?
Unclear. It doesn't have any delete-overlay calls at all. But it does
create and move its own overlay. And it does have a few help-echo
properties.
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-27 16:17 ` Noam Postavsky
@ 2019-04-27 16:49 ` Eli Zaretskii
2019-04-27 19:28 ` Noam Postavsky
0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2019-04-27 16:49 UTC (permalink / raw
To: Noam Postavsky; +Cc: contovob, 35273, leah
> From: Noam Postavsky <npostavs@gmail.com>
> Cc: contovob@tcd.ie, 35273@debbugs.gnu.org, leah@vuxu.org
> Date: Sat, 27 Apr 2019 12:17:25 -0400
>
> >> > > I think it would be better to try to understand how we got such an
> >> > > overlay. Was it deleted, per chance?
> >> >
> >> > I entirely agree with this, but how to check for that?
> >>
> >> But a breakpoint in delete-overlay?
>
> I managed to reproduce (wasn't too hard actually). All the overlay
> deletion seems to come from gnus. I got hits from erase-buffer (called
> by gnus), gnus-kill-all-overlays, and gnus-cite-delete-overlays.
OK, thanks. Then I think it would be better to test the overlay for
being dead in xdisp.c, before we call mouse_face_overlay_overlaps.
Also, a faster test would be to check that the marker's buffer is a
NULL pointer, doing that doesn't require a call marker-position.
WDYT?
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-27 16:49 ` Eli Zaretskii
@ 2019-04-27 19:28 ` Noam Postavsky
2019-04-27 19:35 ` Eli Zaretskii
0 siblings, 1 reply; 18+ messages in thread
From: Noam Postavsky @ 2019-04-27 19:28 UTC (permalink / raw
To: Eli Zaretskii; +Cc: contovob, 35273, leah
[-- Attachment #1: Type: text/plain, Size: 657 bytes --]
tags 35273 + patch
quit
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Noam Postavsky <npostavs@gmail.com>
>> I managed to reproduce (wasn't too hard actually). All the overlay
>> deletion seems to come from gnus. I got hits from erase-buffer (called
>> by gnus), gnus-kill-all-overlays, and gnus-cite-delete-overlays.
>
> OK, thanks. Then I think it would be better to test the overlay for
> being dead in xdisp.c, before we call mouse_face_overlay_overlaps.
> Also, a faster test would be to check that the marker's buffer is a
> NULL pointer, doing that doesn't require a call marker-position.
> WDYT?
Sure, that works. Should I push to emacs-26?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 1172 bytes --]
From 912e336d107cd1bb840cc921b4893bfc0d6cfa98 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Sat, 27 Apr 2019 15:22:11 -0400
Subject: [PATCH] Check if mouse_face_overlay was deleted (Bug#35273)
* src/xdisp.c (note_mouse_highlight): Check if the mouse_face_overlay
actually points to a buffer, before calling
mouse_face_overlay_overlaps on it.
---
src/xdisp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/xdisp.c b/src/xdisp.c
index 0c3754a338..aa6e1bd2df 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -31526,7 +31526,9 @@ note_mouse_highlight (struct frame *f, int x, int y)
is currently hidden to avoid Bug#30519. */
|| (!hlinfo->mouse_face_hidden
&& OVERLAYP (hlinfo->mouse_face_overlay)
- && mouse_face_overlay_overlaps (hlinfo->mouse_face_overlay)))
+ /* It's possible the overlay was deleted (Bug#35273). */
+ && XMARKER (OVERLAY_START (hlinfo->mouse_face_overlay))->buffer
+ && mouse_face_overlay_overlaps (hlinfo->mouse_face_overlay)))
{
/* Find the highest priority overlay with a mouse-face. */
Lisp_Object overlay = Qnil;
--
2.11.0
^ permalink raw reply related [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-27 19:28 ` Noam Postavsky
@ 2019-04-27 19:35 ` Eli Zaretskii
2019-04-28 12:45 ` Noam Postavsky
0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2019-04-27 19:35 UTC (permalink / raw
To: Noam Postavsky; +Cc: contovob, 35273, leah
> From: Noam Postavsky <npostavs@gmail.com>
> Cc: contovob@tcd.ie, 35273@debbugs.gnu.org, leah@vuxu.org
> Date: Sat, 27 Apr 2019 15:28:01 -0400
>
> > OK, thanks. Then I think it would be better to test the overlay for
> > being dead in xdisp.c, before we call mouse_face_overlay_overlaps.
> > Also, a faster test would be to check that the marker's buffer is a
> > NULL pointer, doing that doesn't require a call marker-position.
> > WDYT?
>
> Sure, that works. Should I push to emacs-26?
Yes, please.
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#35273: "Marker does not point anywhere" when reading next article
2019-04-27 19:35 ` Eli Zaretskii
@ 2019-04-28 12:45 ` Noam Postavsky
0 siblings, 0 replies; 18+ messages in thread
From: Noam Postavsky @ 2019-04-28 12:45 UTC (permalink / raw
To: Eli Zaretskii; +Cc: contovob, 35273, leah
tags 35273 fixed
close 35273 26.3
quit
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Noam Postavsky <npostavs@gmail.com>
>> Cc: contovob@tcd.ie, 35273@debbugs.gnu.org, leah@vuxu.org
>> Date: Sat, 27 Apr 2019 15:28:01 -0400
>>
>> > OK, thanks. Then I think it would be better to test the overlay for
>> > being dead in xdisp.c, before we call mouse_face_overlay_overlaps.
>> > Also, a faster test would be to check that the marker's buffer is a
>> > NULL pointer, doing that doesn't require a call marker-position.
>> > WDYT?
>>
>> Sure, that works. Should I push to emacs-26?
>
> Yes, please.
Okay, done.
7cb5364ef5 2019-04-28T08:31:17-04:00 "Check if mouse_face_overlay was deleted (Bug#35273)"
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=7cb5364ef5334de0fb1bc2e470bea450e4567d24
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2019-04-28 12:45 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-04-14 13:42 bug#35273: "Marker does not point anywhere" when reading next article Leah Neukirchen
2019-04-14 16:31 ` Basil L. Contovounesios
2019-04-14 21:19 ` Leah Neukirchen
2019-04-16 12:38 ` Noam Postavsky
2019-04-16 12:50 ` Leah Neukirchen
2019-04-16 13:13 ` Noam Postavsky
2019-04-16 13:21 ` Leah Neukirchen
2019-04-16 13:56 ` Noam Postavsky
2019-04-16 14:04 ` Leah Neukirchen
2019-04-16 15:02 ` Eli Zaretskii
2019-04-20 12:05 ` Noam Postavsky
2019-04-20 13:44 ` Eli Zaretskii
2019-04-20 16:20 ` Eli Zaretskii
2019-04-27 16:17 ` Noam Postavsky
2019-04-27 16:49 ` Eli Zaretskii
2019-04-27 19:28 ` Noam Postavsky
2019-04-27 19:35 ` Eli Zaretskii
2019-04-28 12:45 ` Noam Postavsky
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.