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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>.
.
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 <[hidden email]>.
.

--
Leah Neukirchen  <[hidden email]>  http://leahneukirchen.org/



Reply | Threaded
Open this post in threaded view
|

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

Basil L. Contovounesios
Leah Neukirchen <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Leah Neukirchen
"Basil L. Contovounesios" <[hidden email]> writes:

> Leah Neukirchen <[hidden email]> 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  <[hidden email]>  http://leah.zone



Reply | Threaded
Open this post in threaded view
|

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

Noam Postavsky
Leah Neukirchen <[hidden email]> 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.





Reply | Threaded
Open this post in threaded view
|

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

Leah Neukirchen
Noam Postavsky <[hidden email]> writes:

> Leah Neukirchen <[hidden email]> 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  <[hidden email]>  http://leah.zone



Reply | Threaded
Open this post in threaded view
|

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

Noam Postavsky
Leah Neukirchen <[hidden email]> 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'?



Reply | Threaded
Open this post in threaded view
|

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

Leah Neukirchen
Noam Postavsky <[hidden email]> writes:

> Leah Neukirchen <[hidden email]> 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  <[hidden email]>  http://leah.zone



Reply | Threaded
Open this post in threaded view
|

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

Noam Postavsky
Leah Neukirchen <[hidden email]> writes:

> Noam Postavsky <[hidden email]> 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];





Reply | Threaded
Open this post in threaded view
|

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

Leah Neukirchen
Noam Postavsky <[hidden email]> 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  <[hidden email]>  http://leah.zone



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Noam Postavsky
> From: Noam Postavsky <[hidden email]>
> Date: Tue, 16 Apr 2019 09:56:36 -0400
> Cc: "Basil L. Contovounesios" <[hidden email]>, [hidden email]
>
> 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?