emacs-devel
[Top][All Lists]
Advanced

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

Re: crash on MacOSX


From: Liang Wang
Subject: Re: crash on MacOSX
Date: Sat, 18 Aug 2012 20:00:28 +0800

On Sat, Aug 18, 2012 at 7:33 PM, Eli Zaretskii <address@hidden> wrote:
>> Date: Sat, 18 Aug 2012 18:33:57 +0800
>> From: Liang Wang <address@hidden>
>> Cc: Chong Yidong <address@hidden>
>>
>> This bug is not always reproducible when I debug it inside gdb.  Is it
>> possible that it depends on the loading order of shared libraries?
>
> Unlikely.  The original crash was reported here:
>
>       int font_wid = FRAME_COLUMN_WIDTH (f);
>       int cols = (left_wid + right_wid + font_wid-1) / font_wid; <<<<<
>
> As you see, font_wid is computed from FRAME_COLUMN_WIDTH (f), which
> should never be zero.  I fail to see how this could be dependent on

FRAME_COLUMN_WIDTH (f) is initialized in x_new_font
(src/nsterm.m:6720) before compute_fringe_widths (f, 1) as
  FRAME_COLUMN_WIDTH (f) = font->average_width;

And the right hand side is zero.

> the order of loading shared libraries.  This value depends on the font
> used by the default face of the first frame created when Emacs starts.
> It does not come from any library.
>
> But of course, this is software, so anything's possible.
>
>> When emacs starts successfully, the list of message, "Reading symbols
>> for shared libraries", is longer.
>
> When it does NOT crash, what is the value of font_wid in the above
> snippet?

The value is 7.

>
>> There are two ways to work around this bug.  One is to revert r109641:
>> Fix average font width        calculation on NS.
>> http://lists.gnu.org/archive/html/emacs-diffs/2012-08/msg00322.html.
>> font->average_width is set to zero when bug occurs.
>
> Most probably, this is the reason for the bug.
>



reply via email to

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