bug#37671: 27.0.50; Segmentation fault with --fg-daemon on Linux

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 10 Oct 2019 13:56:46 -0700
> Cc: 37671@debbugs.gnu.org
> 
> As a shot in the dark, does the attached patch fix things for you, or 
> affect the symptoms? The idea is to prevent a reset hlinfo from looking 
> like it's nonempty. (A fancier possibility would be to add one to 
> end_row and end_col everywhere.)
> 
> diff --git a/src/dispextern.h b/src/dispextern.h
> index 7a15e2745b..19f2d3ba6c 100644
> --- a/src/dispextern.h
> +++ b/src/dispextern.h
> @@ -2840,7 +2840,7 @@ #define PRODUCE_GLYPHS(IT)                              
> \
>  reset_mouse_highlight (Mouse_HLInfo *hlinfo)
>  {
>  
> -    hlinfo->mouse_face_beg_row = hlinfo->mouse_face_beg_col = -1;
> +    hlinfo->mouse_face_beg_row = hlinfo->mouse_face_beg_col = 0;

This cannot be right, since zero is a valid column number.

>        /* If mouse highlighting is on, we may need to draw adjacent
>        glyphs using mouse-face highlighting.  */
>        if (area == TEXT_AREA && row->mouse_face_p
> -       && hlinfo->mouse_face_beg_row >= 0
> -       && hlinfo->mouse_face_end_row >= 0)
> +       && hlinfo->mouse_face_beg_row <= hlinfo->mouse_face_end_row)

And this cannot be right because of bidirectional editing support,
whereby beg_row CAN be greater than end_row.

The test whether mouse highlight info is valid should involve the
mouse_face_window and mouse_face_mouse_frame members., and if these
are valid, then the row and column numbers should be valid as well.
If the row or the column are invalid, e somehow failed to update them
when we computed the info and set the frame and the window members.