From: martin rudalics <rudalics@gmx.at>
To: "Jan Djärv" <jan.h.d@swipnet.se>
Cc: Jules Colding <colding@venalicium.dk>, 16049@debbugs.gnu.org
Subject: bug#16049: 24.3.50; Crash on startup on Mac OS X 10.9
Date: Fri, 06 Dec 2013 19:56:51 +0100 [thread overview]
Message-ID: <52A21DF3.6040709@gmx.at> (raw)
In-Reply-To: <04BC6316-338E-4025-A9CC-006F576051C1@swipnet.se>
> The root cause is grow_mini_window in window.c.
>
> It sets w->pixel_height to a large negative value, and it is all downhill from there.
> It is called twice. Right before w->pixel_height += pixel_height;
>
> the values for pixelwise, w->pixel_height, pixel_height, line_height, FRAME_LINE_HEIGTH(f), delta and XINT (height) are:
>
> 1 1 -47 -3 14 13 47
>
> The 1 for w->pixel_height looks wrong.
> This will set w->pixel_height to -46.
> The second call:
>
> 1 -46 -2147483603 .153391685 14 60 0
>
> I'm not sure how this function is supposed to work. pixel_value is negative or it is a huge positive value. Is it relying on overflow?
IIUC this occurs with pixel values not yet assigned. That is, the
minibuffer window still has a line and pixel height of 1 but the frame's
character height has already changed so the relations are wrong.
I had this problem on Windows and did in w32fns.c
/* PXW: This is a duplicate from below. We have to do it here since
otherwise x_set_tool_bar_lines will work with the character sizes
installed by init_frame_faces while the frame's pixel size is still
calculated from a character size of 1 and we subsequently hit the
eassert (height >= 0) assertion in window_box_height. The
non-pixelwise code apparently worked around this because it had one
frame line vs one toolbar line which left us with a zero root
window height which was obviously wrong as well ... */
width = FRAME_TEXT_WIDTH (f);
height = FRAME_TEXT_HEIGHT (f);
FRAME_TEXT_HEIGHT (f) = 0;
SET_FRAME_WIDTH (f, 0);
change_frame_size (f, width, height, 1, 0, 0, 1);
and on GTK where I did in xfns.c completely the same
#ifdef USE_GTK
/* PXW: This is a duplicate from below. We have to do it here since
otherwise x_set_tool_bar_lines will work with the character sizes
installed by init_frame_faces while the frame's pixel size is still
calculated from a character size of 1 and we subsequently hit the
eassert (height >= 0) assertion in window_box_height. The
non-pixelwise code apparently worked around this because it had one
frame line vs one toolbar line which left us with a zero root
window height which was obviously wrong as well ... */
width = FRAME_TEXT_WIDTH (f);
height = FRAME_TEXT_HEIGHT (f);
FRAME_TEXT_HEIGHT (f) = 0;
SET_FRAME_WIDTH (f, 0);
change_frame_size (f, width, height, 1, 0, 0, 1);
#endif /* USE_GTK */
It's a very weird issue but you didn't make it till window_box_height
apparently, so I don't know whether it's related.
martin
next prev parent reply other threads:[~2013-12-06 18:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-04 14:06 bug#16049: 24.3.50; Crash on startup on Mac OS X 10.9 Jules Colding
2013-12-04 14:39 ` martin rudalics
2013-12-04 16:44 ` Jan Djärv
2013-12-04 18:06 ` martin rudalics
2013-12-04 19:39 ` Jules Colding
2013-12-05 7:00 ` martin rudalics
2013-12-05 6:01 ` Jan Djärv
2013-12-05 7:00 ` martin rudalics
2013-12-05 17:35 ` Jan Djärv
2013-12-05 17:43 ` Jan Djärv
2013-12-05 18:13 ` martin rudalics
2013-12-05 19:55 ` Jan Djärv
2013-12-05 18:19 ` Eli Zaretskii
2013-12-05 19:59 ` Jan Djärv
2013-12-05 20:20 ` Eli Zaretskii
2013-12-06 18:32 ` Jan Djärv
2013-12-06 18:56 ` martin rudalics [this message]
2013-12-07 8:25 ` bug#16049: 24.3.50; xdisp.c infloop " Jan Djärv
2013-12-07 9:16 ` Eli Zaretskii
2013-12-07 14:26 ` Jan Djärv
2013-12-07 14:42 ` martin rudalics
2013-12-07 14:57 ` Jules Colding
2013-12-07 15:57 ` Jules Colding
2013-12-05 17:59 ` bug#16049: 24.3.50; Crash on startup " martin rudalics
2013-12-05 18:20 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52A21DF3.6040709@gmx.at \
--to=rudalics@gmx.at \
--cc=16049@debbugs.gnu.org \
--cc=colding@venalicium.dk \
--cc=jan.h.d@swipnet.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.