GNU bug report logs - #21428
24.5; Crash of emacs on OS X, installed via homebrew cask

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Rainer <at> krugs.de, 21428 <at> debbugs.gnu.org
Subject: bug#21428: 24.5; Crash of emacs on OS X, installed via homebrew cask
Date: Fri, 23 Oct 2015 10:02:54 +0200

> However, I noticed that a number of NextStep callback functions start with
> the following code sequence:
>
>    if (!emacsframe->output_data.ns)
>      return;
>
> If `ns' is NULL it would account for the crash. I don't see why we can't
> add it to the windowDidResize: method as well.

I have no idea how threading works on OSX.  Here on GNUStep making the
toolbar visible in update_frame_tool_bar immediately provokes a call of
windowDidResize which calls updateFrameSize with a not yet updated
toolbar height some time before updateFrameSize gets properly called at
the end of update_frame_tool_bar.

So what _could_ happen is that we

(1) Call [toolbar setVisible: YES] in update_frame_tool_bar,

(2) then updateFrameSize tries to calculate

      extra = FRAME_NS_TITLEBAR_HEIGHT (emacsframe)
        + FRAME_TOOLBAR_HEIGHT (emacsframe);

    with an unitialized FRAME_TOOLBAR_HEIGHT for this frame, and

(3) when we finally set

  FRAME_TOOLBAR_HEIGHT (f) =
    NSHeight ([window frameRectForContentRect: NSMakeRect (0, 0, 0, 0)])
    - FRAME_NS_TITLEBAR_HEIGHT (f);

in update_frame_tool_bar it's already too late.

I have no idea how this is supposed to work: If I don't make the tool
bar visible, I don't know its height.  If I don't know its height, I
can't make it visible.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.