bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21428: 24.5; Crash of emacs on OS X, installed via homebrew cask


From: martin rudalics
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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]