bug#16691: 24.3.50; emacs_backtrace.txt

bug#16691: 24.3.50; emacs_backtrace.txt

[Drew Adams]

Backtrace:
011fbc19
011fbc8a
010f02f7
01162209
01004628
0100a3a3
01008963
010080f6
01007da0
010437c5
01041701
010f68ac
01103cee
010f43c5
0117d306
010f3cfa
0117c8b3
010f3c61
010f3448
010f3604
01180389
011c0f7c
01180b88
011805e2
0117f536
0117fe3c
0117a729
0117a787
0117ec30
0117ac19
01180eb7
011806b5
0117ef0e
0117ac19
0117c3b1
0117ed7c
0117a9a3
0117ed7c
0117ac19
01180eb7
011806b5
0117f907
01180296
011c0f7c
01180b88
011808a7
0117f285
0117ac19
0117bf26
0117ed7c
0117ac19
01180eb7
011806b5
0117ef0e
0117ac19
01180eb7
011806b5
0117ef0e
0117ac19
01180eb7
011806b5
0117ef0e
...




In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2014-02-06 on ODIEONE
Bzr revision: 116299 rgm@gnu.org-20140207032552-3ycw6hai2zl7yynq
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

bug#16691: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

??
??:0
w32_backtrace at w32fns.c:8431
emacs_abort at w32fns.c:8463
terminate_due_to_signal at emacs.c:378
die at alloc.c:6761
row_equal_p at dispnew.c:1170
scrolling_window at dispnew.c:4129
update_window at dispnew.c:3392
update_window_tree at dispnew.c:3161
update_frame at dispnew.c:3059
redisplay_internal at xdisp.c:13665
redisplay at xdisp.c:12911
read_char at keyboard.c:2563
read_key_sequence at keyboard.c:9071
command_loop_1 at keyboard.c:1445
internal_condition_case at eval.c:1352
command_loop_2 at keyboard.c:1170
internal_catch at eval.c:1116
command_loop at keyboard.c:1141
recursive_edit_1 at keyboard.c:777
Frecursive_edit at keyboard.c:841
Ffuncall at eval.c:2810
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:2981
Ffuncall at eval.c:2862
Fapply at eval.c:2299
apply1 at eval.c:2586
call_debugger at eval.c:330
do_debug_on_call at eval.c:346
eval_sub at eval.c:2100
Fprogn at eval.c:466
funcall_lambda at eval.c:3040
Ffuncall at eval.c:2874
eval_sub at eval.c:2155
Fprogn at eval.c:466
Flet at eval.c:974
eval_sub at eval.c:2131
Fif at eval.c:417
eval_sub at eval.c:2131
Fprogn at eval.c:466
funcall_lambda at eval.c:3040
Ffuncall at eval.c:2874
Fapply at eval.c:2352
Ffuncall at eval.c:2794
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:2981
apply_lambda at eval.c:2922
eval_sub at eval.c:2228
Fprogn at eval.c:466
FletX at eval.c:904
eval_sub at eval.c:2131
Fprogn at eval.c:466
funcall_lambda at eval.c:3040
Ffuncall at eval.c:2874
eval_sub at eval.c:2155
Fprogn at eval.c:466
funcall_lambda at eval.c:3040
Ffuncall at eval.c:2874
eval_sub at eval.c:2155
Fprogn at eval.c:466
funcall_lambda at eval.c:3040
Ffuncall at eval.c:2874
eval_sub at eval.c:2155
??
??:0

bug#16691: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

merge 16660 16691
thanks

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 8 Feb 2014 20:22:20 +0100
> Cc: 16691@debbugs.gnu.org
> 
> w32_backtrace at w32fns.c:8431
> emacs_abort at w32fns.c:8463
> terminate_due_to_signal at emacs.c:378
> die at alloc.c:6761
> row_equal_p at dispnew.c:1170
> scrolling_window at dispnew.c:4129

This is a duplicate of 16660.

Since this started happening only lately, Martin, could you please see
if some of your changes could possibly disrupt the glyph row's hash
values?

bug#16691: 24.3.50; emacs_backtrace.txt

[martin rudalics]

> Since this started happening only lately, Martin, could you please see
> if some of your changes could possibly disrupt the glyph row's hash
> values?

If you told me how I could have done that, maybe.  I don't have the
slightest idea.

martin

bug#16691: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sat, 08 Feb 2014 21:06:14 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Juanma Barranquero <lekktu@gmail.com>, drew.adams@oracle.com, 
>  16691@debbugs.gnu.org, control@debbugs.gnu.org
> 
> > Since this started happening only lately, Martin, could you please see
> > if some of your changes could possibly disrupt the glyph row's hash
> > values?
> 
> If you told me how I could have done that, maybe.  I don't have the
> slightest idea.

I don't know if you did that.  I just took a look at the latest
changes preceding the first revno where Drew reported this.

As to how this could happen: did any of your changes affect the 'used'
field of the glyph_row structure, under any circumstances?

bug#16691: 24.3.50; emacs_backtrace.txt

[Glenn Morris]

If you bcc'd control@debbugs rather than cc'ing, you would not have the
problem where people, including yourself, include it on all future replies.

You've previously said you won't do that, but I ask you to reconsider:

http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00804.html

>> If control@debbugs goes in BCC, people will become confused about
>> those weird commands at the beginning of the message.

That supposes that people 1) read the address list (my experience is
that they do not, you're proving it in this thread); and 2) use it
figure out what "weird commands" might mean (I doubt it).

By not using bcc, you require everyone who might reply to you to check
and possibly edit the reply list, or to start every single message with
"stop". (Or to use something like message-dont-reply-to-names, which is
a good idea anyway.)

If you really think people are confused by these commands, you should
send them in a totally separate message. Or preface them with a #
comment to explain them.

bug#16691: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: martin rudalics <rudalics@gmx.at>,  16691@debbugs.gnu.org,  lekktu@gmail.com
> Date: Sat, 08 Feb 2014 15:40:25 -0500
> 
> 
> If you bcc'd control@debbugs rather than cc'ing, you would not have the
> problem where people, including yourself, include it on all future replies.
> 
> You've previously said you won't do that, but I ask you to reconsider:
> 
> http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00804.html
> 
> >> If control@debbugs goes in BCC, people will become confused about
> >> those weird commands at the beginning of the message.
> 
> That supposes that people 1) read the address list (my experience is
> that they do not, you're proving it in this thread); and 2) use it
> figure out what "weird commands" might mean (I doubt it).
> 
> By not using bcc, you require everyone who might reply to you to check
> and possibly edit the reply list, or to start every single message with
> "stop". (Or to use something like message-dont-reply-to-names, which is
> a good idea anyway.)

(Why does this deserve a discussion?  A few messages bounced, so
what?)

I use this facility so infrequently that I'd probably forget to use
BCC anyway, like I always forget that a new bug report cannot be
merged with a closed one.

If you ask me, this all stems from the fact that debbugs is less
helpful than it could have been.  It could, for example, be smarter
about merging, and it could take commands from messages addressed to
NNNN@debbugs.gnu.org, not just control@.  If you want to solve these
problems, that's the only sure way.

bug#16691: 24.3.50; emacs_backtrace.txt

[Glenn Morris]

Eli Zaretskii wrote:

> (Why does this deserve a discussion?  A few messages bounced, so
> what?)

OK, fine, keep confusing everyone who replies to you.

> If you ask me, this all stems from the fact that debbugs is less
> helpful than it could have been.  It could, for example, be smarter
> about merging, and it could take commands from messages addressed to
> NNNN@debbugs.gnu.org, not just control@.  If you want to solve these
> problems, that's the only sure way.

I disagree, and since no-one but me does any work on debbugs.gnu.org, I
would not expect anything to happen in this area.

bug#16691: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 >>> Since this started happening only lately, Martin, could you please see
 >>> if some of your changes could possibly disrupt the glyph row's hash
 >>> values?
 >> If you told me how I could have done that, maybe.  I don't have the
 >> slightest idea.
 >
 > I don't know if you did that.  I just took a look at the latest
 > changes preceding the first revno where Drew reported this.

My last change before that was to process frame alpha earlier from
revision 116242.  While being a very dubious change, I can't imagine how
it could affect hash values.

 > As to how this could happen: did any of your changes affect the 'used'
 > field of the glyph_row structure, under any circumstances?

I don't understand the glyph_row structure and hopefully never ever have
touched it.  The only possibly related change is that of re-introducing
an adjust_window_margins call in window_resize_apply in revision 116307,
but this happened clearly after Bug#16660.

martin

bug#16691: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sun, 09 Feb 2014 12:04:16 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: lekktu@gmail.com, drew.adams@oracle.com, 16691@debbugs.gnu.org
> 
>  > As to how this could happen: did any of your changes affect the 'used'
>  > field of the glyph_row structure, under any circumstances?
> 
> I don't understand the glyph_row structure and hopefully never ever have
> touched it.  The only possibly related change is that of re-introducing
> an adjust_window_margins call in window_resize_apply in revision 116307,
> but this happened clearly after Bug#16660.

OK, thanks for checking.

bug#16691: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 >> I don't understand the glyph_row structure and hopefully never ever have
 >> touched it.

But while you're here could you please try to explain the following
issues wrt three members of glyph_row:

- short used[1 + LAST_AREA]: What does "Number of glyphs actually filled
   in areas." mean?  Does this mean that for example the first element is
   zero when the left margin doesn't exist?

- int x, y: Where and how are these set for a particular row (including
   header- and mode-line) and when and how are these eventually consumed?
   This is the greatest mystery for me so far.

- int visible_height: "Partially visible rows may be found at the top
   and bottom of a window."  Is it true that we can draw partially
   visible rows at the top of the window?

Thanks, martin

bug#16691: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sun, 09 Feb 2014 19:58:12 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: lekktu@gmail.com, drew.adams@oracle.com, 16691@debbugs.gnu.org
> 
> - short used[1 + LAST_AREA]: What does "Number of glyphs actually filled
>    in areas." mean?  Does this mean that for example the first element is
>    zero when the left margin doesn't exist?

Not necessarily: the margin could exist, but be empty.  And note that
in frame glyph matrices (used on a TTY), there's only one area: the
TEXT_AREA; the marginal areas don't have their glyphs[] arrays
allocated.

> - int x, y: Where and how are these set for a particular row (including
>    header- and mode-line) and when and how are these eventually consumed?
>    This is the greatest mystery for me so far.

They are assigned in display_line and display_string.  Examples from
display_line:

  row->y = it->current_y;
  [...]
  if (it->current_x - it->pixel_width < it->first_visible_x)
    row->x = x - it->first_visible_x;

Mode line and header line are generated from strings, so look in
display_mode_line and display_string.

Not sure what you mean by "consumed".  Consumed by whom and for what
purposes?

> - int visible_height: "Partially visible rows may be found at the top
>    and bottom of a window."  Is it true that we can draw partially
>    visible rows at the top of the window?

I think this is only possible when a single row is too large to fit a
window.

bug#16691: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 >> - int x, y: Where and how are these set for a particular row (including
 >>    header- and mode-line) and when and how are these eventually consumed?
 >>    This is the greatest mystery for me so far.
 >
 > They are assigned in display_line and display_string.  Examples from
 > display_line:
 >
 >   row->y = it->current_y;

Does the value set here account for extra_line_spacing or is the latter
(as I presume) handled separately?

 >   [...]
 >   if (it->current_x - it->pixel_width < it->first_visible_x)
 >     row->x = x - it->first_visible_x;
 >
 > Mode line and header line are generated from strings, so look in
 > display_mode_line and display_string.

I tried that but never found anything useful there.  I suppose the
header line has current_y always set to 0.  But the mode line?

My confusion comes partly from window_text_bottom_y which returns a
position above the mode line, so apparently the mode line is handled
separately.  But the header line is included in the height returned.
And window_box_height does not include the header line in the return
value.

I understand that most of these are handled by some kind of internal
magic but I can't locate that magic yet.

 > Not sure what you mean by "consumed".  Consumed by whom and for what
 > purposes?

I suppose when exposing the window (another part of Emacs display which
I don't understand yet).  What would current_y else be used for?

 >> - int visible_height: "Partially visible rows may be found at the top
 >>    and bottom of a window."  Is it true that we can draw partially
 >>    visible rows at the top of the window?
 >
 > I think this is only possible when a single row is too large to fit a
 > window.

I see.  So this is not about having the top of a line only partially
visible.

martin

bug#16691: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Mon, 10 Feb 2014 09:14:33 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: lekktu@gmail.com, drew.adams@oracle.com, 16691@debbugs.gnu.org
> 
>  >> - int x, y: Where and how are these set for a particular row (including
>  >>    header- and mode-line) and when and how are these eventually consumed?
>  >>    This is the greatest mystery for me so far.
>  >
>  > They are assigned in display_line and display_string.  Examples from
>  > display_line:
>  >
>  >   row->y = it->current_y;
> 
> Does the value set here account for extra_line_spacing or is the latter
> (as I presume) handled separately?

The y-coordinate of the row does include the extra_line_spacing, it
must.  More accurately, the next row gets its y coordinate increased
due to extra line spacing of the previous row.

We calculate the value inside PRODUCE_GLYPHS (which expands into a
call to x_produce_glyphs in a GUI session), and then enlarge
it->descent by the computed value.  Then display_line, which calls
PRODUCE_GLYPHS, copies these values from 'struct it' to the glyph row,
updates row->height accordingly, and uses row->height to increment
row->y when it advances to the next row (see near the end of
display_line).

>  >   [...]
>  >   if (it->current_x - it->pixel_width < it->first_visible_x)
>  >     row->x = x - it->first_visible_x;
>  >
>  > Mode line and header line are generated from strings, so look in
>  > display_mode_line and display_string.
> 
> I tried that but never found anything useful there.  I suppose the
> header line has current_y always set to 0.  But the mode line?

The magic hides in init_iterator, which is called by display_mode_line:

  /* Use one of the mode line rows of W's desired matrix if
     appropriate.  */
  if (row == NULL)
    {
      if (base_face_id == MODE_LINE_FACE_ID
	  || base_face_id == MODE_LINE_INACTIVE_FACE_ID)
	row = MATRIX_MODE_LINE_ROW (w->desired_matrix);
      else if (base_face_id == HEADER_LINE_FACE_ID)
	row = MATRIX_HEADER_LINE_ROW (w->desired_matrix);
    }

IOW, we rely on the fact that the header line is always the first row,
and the mode line is the last one.

>  > Not sure what you mean by "consumed".  Consumed by whom and for what
>  > purposes?
> 
> I suppose when exposing the window (another part of Emacs display which
> I don't understand yet).  What would current_y else be used for?

Why are we suddenly talking about current_y?  There's no such member
in the glyph_row structure.

If you meant row->y, then it is used in many different places,
including the display back-end, various redisplay optimizations (which
compare rows of current and desired matrices), functions that find
buffer/string positions that correspond to a mouse click, and move_it_*
functions which simulate display, to name just a few.

If you meant something else, please elaborate.

bug#16691: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 >> I suppose when exposing the window (another part of Emacs display which
 >> I don't understand yet).  What would current_y else be used for?
 >
 > Why are we suddenly talking about current_y?

Sorry, I meant row->y.

 > There's no such member
 > in the glyph_row structure.
 >
 > If you meant row->y, then it is used in many different places,
 > including the display back-end,

Where is the display back-end?  If it's update_window we there set

       yb = window_text_bottom_y (w);

and then

	  mode_line_row->y = yb;

so any prior notion of that row's y is lost.  And for the header line we
do

	  header_line_row->y = 0;

But this still doesn't use row->y.  Where is the backend that uses
row->y to determine where on the screen to draw that row?

martin

bug#16691: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Mon, 10 Feb 2014 19:35:25 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: lekktu@gmail.com, drew.adams@oracle.com, 16691@debbugs.gnu.org
> 
>  > If you meant row->y, then it is used in many different places,
>  > including the display back-end,
> 
> Where is the display back-end?  If it's update_window

It is _called_ by update_window.  In update_text_area, you will see
the calls to rif->write_glyphs, which eventually calls the back-end
(xterm.c, w32term.c, term.c, etc.).

> we there set
> 
>        yb = window_text_bottom_y (w);
> 
> and then
> 
> 	  mode_line_row->y = yb;
> 
> so any prior notion of that row's y is lost.  And for the header line we
> do
> 
> 	  header_line_row->y = 0;
> 
> But this still doesn't use row->y.  Where is the backend that uses
> row->y to determine where on the screen to draw that row?

Are you talking only about the mode line and the header line?  If so,
then yes, those rows don't need the y coordinate, as they "know" where
it is in advance.

I thought you were asking a more general question about row->x and
row->y.

bug#16691: 24.3.50; emacs_backtrace.txt

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 10 Feb 2014 19:35:25 +0100
>> From: martin rudalics <rudalics@gmx.at>
>> CC: lekktu@gmail.com, drew.adams@oracle.com, 16691@debbugs.gnu.org
>> 
>>  > If you meant row->y, then it is used in many different places,
>>  > including the display back-end,
>> 
>> Where is the display back-end?  If it's update_window
>
> It is _called_ by update_window.  In update_text_area, you will see
> the calls to rif->write_glyphs, which eventually calls the back-end
> (xterm.c, w32term.c, term.c, etc.).
>
>> we there set
>> 
>>        yb = window_text_bottom_y (w);
>> 
>> and then
>> 
>> 	  mode_line_row->y = yb;
>> 
>> so any prior notion of that row's y is lost.  And for the header line we
>> do
>> 
>> 	  header_line_row->y = 0;
>> 
>> But this still doesn't use row->y.  Where is the backend that uses
>> row->y to determine where on the screen to draw that row?
>
> Are you talking only about the mode line and the header line?  If so,
> then yes, those rows don't need the y coordinate, as they "know" where
> it is in advance.
>
> I thought you were asking a more general question about row->x and
> row->y.

It's unclear what the situation in this bug report is, or who is waiting
for more info from whom.  :-)  Is this still an issue?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#16691: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: martin rudalics <rudalics@gmx.at>,  16660@debbugs.gnu.org,  16691@debbugs.gnu.org,  lekktu@gmail.com,  drew.adams@oracle.com
> Date: Sat, 26 Dec 2015 14:26:32 +0100
> 
> It's unclear what the situation in this bug report is, or who is waiting
> for more info from whom.  :-)  Is this still an issue?

Not for me, I closed it long ago.

Closing again.