bug#35273: "Marker does not point anywhere" when reading next article

bug#35273: "Marker does not point anywhere" when reading next article

[Leah Neukirchen]

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/

bug#35273: "Marker does not point anywhere" when reading next article

[Basil L. Contovounesios]

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

bug#35273: "Marker does not point anywhere" when reading next article

[Leah Neukirchen]

"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

bug#35273: "Marker does not point anywhere" when reading next article

[Noam Postavsky]

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.

bug#35273: "Marker does not point anywhere" when reading next article

[Leah Neukirchen]

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

bug#35273: "Marker does not point anywhere" when reading next article

[Noam Postavsky]

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'?

bug#35273: "Marker does not point anywhere" when reading next article

[Leah Neukirchen]

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

bug#35273: "Marker does not point anywhere" when reading next article

[Noam Postavsky]

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];

bug#35273: "Marker does not point anywhere" when reading next article

[Leah Neukirchen]

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

bug#35273: "Marker does not point anywhere" when reading next article

[Eli Zaretskii]

> 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?

bug#35273: "Marker does not point anywhere" when reading next article

[Noam Postavsky]

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?

bug#35273: "Marker does not point anywhere" when reading next article

[Eli Zaretskii]

> 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?

bug#35273: "Marker does not point anywhere" when reading next article

[Eli Zaretskii]

> 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?

bug#35273: "Marker does not point anywhere" when reading next article

[Noam Postavsky]

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.

bug#35273: "Marker does not point anywhere" when reading next article

[Eli Zaretskii]

> 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?

bug#35273: "Marker does not point anywhere" when reading next article

[Noam Postavsky]

[-- 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

bug#35273: "Marker does not point anywhere" when reading next article

[Eli Zaretskii]

> 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.

bug#35273: "Marker does not point anywhere" when reading next article

[Noam Postavsky]

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