crash on MacOSX

crash on MacOSX

[Liang Wang]

Hi,

I build latest trunk (--with-ns) on Mac OS X 10.7.4 but it fails to start.

Error message is

~/src/emacs/trunk$ ./nextstep/Emacs.app/Contents/MacOS/Emacs -Q
Arithmetic error

Here is backtrace.

~/src/emacs/trunk$ gdb --args ./nextstep/Emacs.app/Contents/MacOS/Emacs -Q
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov  3 21:59:02 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for
shared libraries .......... done

(gdb) r
Starting program:
/Users/wangliang/src/emacs/trunk/nextstep/Emacs.app/Contents/MacOS/Emacs
-Q
Reading symbols for shared libraries
+++++++++.............................................................................................................................
done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done

Program received signal EXC_ARITHMETIC, Arithmetic exception.
0x0000000100178c2f in compute_fringe_widths (f=0x102844460, redraw=1)
at fringe.c:1361
1361	      int cols = (left_wid + right_wid + font_wid-1) / font_wid;
(gdb) p font_wid
$1 = 0
(gdb) bt
#0  0x0000000100178c2f in compute_fringe_widths (f=0x102844460,
redraw=1) at fringe.c:1361
#1  0x0000000100193b12 in x_new_font (f=0x102844460, font_object=0,
fontset=15) at nsterm.m:6740
#2  0x0000000100012ea6 in x_set_font (f=0x102844460, arg=4317066305,
oldval=4320145466) at frame.c:3255
#3  0x00000001000133ca in x_set_frame_parameters (f=0x7fff5fbfead0,
alist=0) at frame.c:2845
#4  0x0000000100013b9f in x_default_parameter (f=0x102844460, alist=0,
prop=4370524474, deflt=4317066049, xprop=0x8 <Address 0x8 out of
bounds>, xclass=0x0, type=RES_TYPE_STRING) at frame.c:3900
#5  0x0000000100196940 in Fx_create_frame (parms=4374394230) at nsfns.m:1258
#6  0x000000010011a053 in Ffuncall (nargs=4337189984,
args=0x10011a20c) at eval.c:2823
#7  0x0000000100153688 in exec_byte_code (bytestr=15,
vector=140734799801600, maxdepth=48, args_template=4296357589,
nargs=4300727136, args=0x1004f2cc0) at bytecode.c:898
#8  0x000000010011cc42 in funcall_lambda (fun=140734799801696,
nargs=1, arg_vector=0x7fff5fbfed60) at eval.c:3055
#9  0x000000010011a137 in Ffuncall (nargs=2, args=0x1048cebba) at eval.c:2872
#10 0x0000000100153688 in exec_byte_code (bytestr=15,
vector=140734799802000, maxdepth=48, args_template=4299696432,
nargs=4300727136, args=0x1004f2cc0) at bytecode.c:898
#11 0x000000010011cc42 in funcall_lambda (fun=140734799802096,
nargs=1, arg_vector=0x7fff5fbfeef0) at eval.c:3055
#12 0x000000010011a137 in Ffuncall (nargs=2, args=0x1048d4ada) at eval.c:2872
#13 0x0000000100153688 in exec_byte_code (bytestr=15,
vector=140734799802416, maxdepth=64, args_template=4296367232,
nargs=4300727136, args=0x1004f2cc0) at bytecode.c:898
#14 0x000000010011cc42 in funcall_lambda (fun=140734799802512,
nargs=0, arg_vector=0x7fff5fbff090) at eval.c:3055
#15 0x000000010011a137 in Ffuncall (nargs=2, args=0x104863f6a) at eval.c:2872
#16 0x0000000100153688 in exec_byte_code (bytestr=15,
vector=140734799802928, maxdepth=0, args_template=4299928947,
nargs=4300727136, args=0x1004f2cc0) at bytecode.c:898
#17 0x000000010011a137 in Ffuncall (nargs=1, args=0x104863cfa) at eval.c:2872
#18 0x0000000100153688 in exec_byte_code (bytestr=15,
vector=140734799803264, maxdepth=0, args_template=4299931194,
nargs=4300727136, args=0x1004f2cc0) at bytecode.c:898
#19 0x000000010011c2e2 in apply_lambda (fun=140734799803360, args=0)
at eval.c:2932
#20 0x000000010011be74 in eval_sub (form=4297634341) at eval.c:2204
#21 0x000000010011992d in Feval (form=4370601462, lexical=4297634429)
at eval.c:2021
#22 0x000000010011d536 in internal_condition_case (bfun=0x1000a9d50
<top_level_2>, handlers=4320212330, hfun=0x1000b4f40 <cmd_error>) at
eval.c:1308
#23 0x00000001000b53ab in top_level_1 (ignore=4297634341) at keyboard.c:1221
#24 0x000000010011d63b in internal_catch (tag=4297634341,
func=0x1000b5370 <top_level_1>, arg=4297634341) at eval.c:1065
#25 0x00000001000b54c2 in command_loop [inlined] () at
/Users/wangliang/src/emacs/trunk/src/keyboard.c:1176
#26 0x00000001000b54c2 in recursive_edit_1 () at keyboard.c:804
#27 0x00000001000a590d in Frecursive_edit () at keyboard.c:868
#28 0x00000001000a256a in main (argc=25241098, argv=0x7fff5fbff920) at
emacs.c:1666
(gdb)

Re: crash on MacOSX

[Liang Wang]

On Sat, Aug 18, 2012 at 12:35 PM, Liang Wang <netcasper@gmail.com> wrote:
> Hi,
>
> I build latest trunk (--with-ns) on Mac OS X 10.7.4 but it fails to start.
>
> Error message is
>
> ~/src/emacs/trunk$ ./nextstep/Emacs.app/Contents/MacOS/Emacs -Q
> Arithmetic error
>
> Here is backtrace.
>
> ~/src/emacs/trunk$ gdb --args ./nextstep/Emacs.app/Contents/MacOS/Emacs -Q
> GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov  3 21:59:02 UTC 2011)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "x86_64-apple-darwin"...Reading symbols for
> shared libraries .......... done
>
> (gdb) r
> Starting program:
> /Users/wangliang/src/emacs/trunk/nextstep/Emacs.app/Contents/MacOS/Emacs
> -Q
> Reading symbols for shared libraries
> +++++++++.............................................................................................................................
> done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
>

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?
When emacs starts successfully, the list of message, "Reading symbols
for shared libraries", is longer.

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.

I'm not sure if it is related to this patch directly.  Since, the
other way is to compile nsfont.m with -g3 -O0.


Liang

Re: crash on MacOSX

[Eli Zaretskii]

> Date: Sat, 18 Aug 2012 18:33:57 +0800
> From: Liang Wang <netcasper@gmail.com>
> Cc: Chong Yidong <cyd@gnu.org>
> 
> 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
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?

> 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.

Re: crash on MacOSX

[Liang Wang]

On Sat, Aug 18, 2012 at 7:33 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 18 Aug 2012 18:33:57 +0800
>> From: Liang Wang <netcasper@gmail.com>
>> Cc: Chong Yidong <cyd@gnu.org>
>>
>> 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.
>

Re: crash on MacOSX

[Liang Wang]

On Sat, Aug 18, 2012 at 12:35 PM, Liang Wang <netcasper@gmail.com> wrote:
> Hi,
>
> I build latest trunk (--with-ns) on Mac OS X 10.7.4 but it fails to start.

I tried ./configure --with-ns CC=clang LD=clang.  And then I don't see
this problem.  It could be a compiler bug.

>
> Error message is
>
> ~/src/emacs/trunk$ ./nextstep/Emacs.app/Contents/MacOS/Emacs -Q
> Arithmetic error
>
> Here is backtrace.
>
> ~/src/emacs/trunk$ gdb --args ./nextstep/Emacs.app/Contents/MacOS/Emacs -Q
> GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov  3 21:59:02 UTC 2011)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "x86_64-apple-darwin"...Reading symbols for
> shared libraries .......... done
>
> (gdb) r
> Starting program:
> /Users/wangliang/src/emacs/trunk/nextstep/Emacs.app/Contents/MacOS/Emacs
> -Q
> Reading symbols for shared libraries
> +++++++++.............................................................................................................................
> done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
>
> Program received signal EXC_ARITHMETIC, Arithmetic exception.
> 0x0000000100178c2f in compute_fringe_widths (f=0x102844460, redraw=1)
> at fringe.c:1361
> 1361          int cols = (left_wid + right_wid + font_wid-1) / font_wid;
> (gdb) p font_wid
> $1 = 0
> (gdb) bt
> #0  0x0000000100178c2f in compute_fringe_widths (f=0x102844460,
> redraw=1) at fringe.c:1361
> #1  0x0000000100193b12 in x_new_font (f=0x102844460, font_object=0,
> fontset=15) at nsterm.m:6740
> #2  0x0000000100012ea6 in x_set_font (f=0x102844460, arg=4317066305,
> oldval=4320145466) at frame.c:3255
> #3  0x00000001000133ca in x_set_frame_parameters (f=0x7fff5fbfead0,
> alist=0) at frame.c:2845
> #4  0x0000000100013b9f in x_default_parameter (f=0x102844460, alist=0,
> prop=4370524474, deflt=4317066049, xprop=0x8 <Address 0x8 out of
> bounds>, xclass=0x0, type=RES_TYPE_STRING) at frame.c:3900
> #5  0x0000000100196940 in Fx_create_frame (parms=4374394230) at nsfns.m:1258
> #6  0x000000010011a053 in Ffuncall (nargs=4337189984,
> args=0x10011a20c) at eval.c:2823
> #7  0x0000000100153688 in exec_byte_code (bytestr=15,
> vector=140734799801600, maxdepth=48, args_template=4296357589,
> nargs=4300727136, args=0x1004f2cc0) at bytecode.c:898
> #8  0x000000010011cc42 in funcall_lambda (fun=140734799801696,
> nargs=1, arg_vector=0x7fff5fbfed60) at eval.c:3055
> #9  0x000000010011a137 in Ffuncall (nargs=2, args=0x1048cebba) at eval.c:2872
> #10 0x0000000100153688 in exec_byte_code (bytestr=15,
> vector=140734799802000, maxdepth=48, args_template=4299696432,
> nargs=4300727136, args=0x1004f2cc0) at bytecode.c:898
> #11 0x000000010011cc42 in funcall_lambda (fun=140734799802096,
> nargs=1, arg_vector=0x7fff5fbfeef0) at eval.c:3055
> #12 0x000000010011a137 in Ffuncall (nargs=2, args=0x1048d4ada) at eval.c:2872
> #13 0x0000000100153688 in exec_byte_code (bytestr=15,
> vector=140734799802416, maxdepth=64, args_template=4296367232,
> nargs=4300727136, args=0x1004f2cc0) at bytecode.c:898
> #14 0x000000010011cc42 in funcall_lambda (fun=140734799802512,
> nargs=0, arg_vector=0x7fff5fbff090) at eval.c:3055
> #15 0x000000010011a137 in Ffuncall (nargs=2, args=0x104863f6a) at eval.c:2872
> #16 0x0000000100153688 in exec_byte_code (bytestr=15,
> vector=140734799802928, maxdepth=0, args_template=4299928947,
> nargs=4300727136, args=0x1004f2cc0) at bytecode.c:898
> #17 0x000000010011a137 in Ffuncall (nargs=1, args=0x104863cfa) at eval.c:2872
> #18 0x0000000100153688 in exec_byte_code (bytestr=15,
> vector=140734799803264, maxdepth=0, args_template=4299931194,
> nargs=4300727136, args=0x1004f2cc0) at bytecode.c:898
> #19 0x000000010011c2e2 in apply_lambda (fun=140734799803360, args=0)
> at eval.c:2932
> #20 0x000000010011be74 in eval_sub (form=4297634341) at eval.c:2204
> #21 0x000000010011992d in Feval (form=4370601462, lexical=4297634429)
> at eval.c:2021
> #22 0x000000010011d536 in internal_condition_case (bfun=0x1000a9d50
> <top_level_2>, handlers=4320212330, hfun=0x1000b4f40 <cmd_error>) at
> eval.c:1308
> #23 0x00000001000b53ab in top_level_1 (ignore=4297634341) at keyboard.c:1221
> #24 0x000000010011d63b in internal_catch (tag=4297634341,
> func=0x1000b5370 <top_level_1>, arg=4297634341) at eval.c:1065
> #25 0x00000001000b54c2 in command_loop [inlined] () at
> /Users/wangliang/src/emacs/trunk/src/keyboard.c:1176
> #26 0x00000001000b54c2 in recursive_edit_1 () at keyboard.c:804
> #27 0x00000001000a590d in Frecursive_edit () at keyboard.c:868
> #28 0x00000001000a256a in main (argc=25241098, argv=0x7fff5fbff920) at
> emacs.c:1666
> (gdb)

Re: crash on MacOSX

[Alp Aker]

> This bug is not always reproducible when I debug it inside gdb.
[...]
> There are two ways to work around this bug.  One is to revert r109641
[...]
> I'm not sure if it is related to this patch directly.  Since, the
> other way is to compile nsfont.m with -g3 -O0.
[..]
> I tried ./configure --with-ns CC=clang LD=clang.  And then I don't see
> this problem.  It could be a compiler bug.

One problem with r109641 that *might* explain your observations is
that it introduced code that initialized a static string using a char
array that wasn't null terminated.  This would result in the string's
containing an unexpected number of extra characters (possibly
non-ascii, as well), but the number and identity of the unexpected
chars would vary between emacs instances. Compiling with -g3 -O0,
however, leads to the same extra chars appearing in the string across
different invocations of emacs, and when compiling with Clang the
string has only the expected characters.

This might not explain the exception you're seeing (there are likely
other issues with 109641; e.g., the #ifdef NS_IMPL_COCOA portion of
ns_ascii_average_width is, I'm fairly sure, incorrect, but I haven't
sorted out yet what the correct thing for it to do is).  But please
try building 109677 and see if that fixes the problem for you.

Re: crash on MacOSX

[Liang Wang]

On Sun, Aug 19, 2012 at 9:40 AM, Alp Aker <alptekin.aker@gmail.com> wrote:
>> This bug is not always reproducible when I debug it inside gdb.
> [...]
>> There are two ways to work around this bug.  One is to revert r109641
> [...]
>> I'm not sure if it is related to this patch directly.  Since, the
>> other way is to compile nsfont.m with -g3 -O0.
> [..]
>> I tried ./configure --with-ns CC=clang LD=clang.  And then I don't see
>> this problem.  It could be a compiler bug.
>
> One problem with r109641 that *might* explain your observations is
> that it introduced code that initialized a static string using a char
> array that wasn't null terminated.  This would result in the string's
> containing an unexpected number of extra characters (possibly
> non-ascii, as well), but the number and identity of the unexpected
> chars would vary between emacs instances. Compiling with -g3 -O0,
> however, leads to the same extra chars appearing in the string across
> different invocations of emacs, and when compiling with Clang the
> string has only the expected characters.
>
> This might not explain the exception you're seeing (there are likely
> other issues with 109641; e.g., the #ifdef NS_IMPL_COCOA portion of
> ns_ascii_average_width is, I'm fairly sure, incorrect, but I haven't
> sorted out yet what the correct thing for it to do is).  But please
> try building 109677 and see if that fixes the problem for you.

Yes, I started emacs several times successfully.  Thank you.

Liang

Re: crash on MacOSX

[Adrian Robert]

Alp Aker <alptekin.aker <at> gmail.com> writes:

> 
>; e.g., the #ifdef NS_IMPL_COCOA portion of
> ns_ascii_average_width is, I'm fairly sure, incorrect, but I haven't
> sorted out yet what the correct thing for it to do is).

I would just remove that portion, or make it a loop that checks
the advancement for each character individually.  Still, you
would need to be sure that all 95 glyphs are found named as their
ascii characters for that to work.  This is why the ns_char_width
impl used advancementForGlyph only as a potential shortcut and
not the sole approach.

-Adrian