* 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 public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).