The very latest emacs (25.1.50) segfault

The very latest emacs (25.1.50) segfault

[Masaru Nomiya]

Hello,

masaru@linux-uw5l:/tmp/tes/emacs> src/emacs
Fatal error 11: Segmentation fault
Backtrace:
src/emacs[0x4fb622]
src/emacs[0x4e3384]
src/emacs[0x4fa52e]
src/emacs[0x4fa733]
src/emacs[0x4fa76a]
/lib64/libpthread.so.0(+0xf1f0)[0x7f8fb6d871f0]
src/emacs[0x5aeda9]
src/emacs[0x5b0aea]
src/emacs[0x5608c5]
src/emacs[0x553570]
src/emacs[0x586235]
src/emacs[0x552fc2]
src/emacs[0x553383]
src/emacs[0x552001]
src/emacs[0x42b766]
src/emacs[0x43832f]
src/emacs[0x5a2b0c]
src/emacs[0x5a6acb]
src/emacs[0x4419a8]
src/emacs[0x43fd1a]
src/emacs[0x441be1]
src/emacs[0x443f6c]
src/emacs[0x4446b6]
src/emacs[0x46fcb9]
src/emacs[0x553564]
src/emacs[0x586235]
src/emacs[0x552fc2]
src/emacs[0x553383]
src/emacs[0x586235]
src/emacs[0x552fc2]
src/emacs[0x553383]
src/emacs[0x586235]
src/emacs[0x552fc2]
src/emacs[0x553383]
src/emacs[0x586235]
src/emacs[0x552fc2]
src/emacs[0x553383]
src/emacs[0x586235]
src/emacs[0x552fc2]
src/emacs[0x553383]
src/emacs[0x586235]
...
Segmentation fault

Thanks,

--
M. Nomiya

Re: The very latest emacs (25.1.50) segfault

[Eli Zaretskii]

> Date: Sun, 10 Jan 2016 13:55:49 +0900
> From: Masaru Nomiya <nomiya@galaxy.dti.ne.jp>
> 
> masaru@linux-uw5l:/tmp/tes/emacs> src/emacs
> Fatal error 11: Segmentation fault
> Backtrace:
> src/emacs[0x4fb622]
> src/emacs[0x4e3384]
> src/emacs[0x4fa52e]
> src/emacs[0x4fa733]
> src/emacs[0x4fa76a]
> /lib64/libpthread.so.0(+0xf1f0)[0x7f8fb6d871f0]
> src/emacs[0x5aeda9]
> src/emacs[0x5b0aea]

Can you use the procedure described in the node "Crashing" of the
Emacs User manual to produce human-readable backtrace with file names
and line numbers out of this?  Otherwise it's impossible for us to
interpret this data.

Thanks.

Re: The very latest emacs (25.1.50) segfault

[Masaru Nomiya]

Hello,

In the Message; 

  Subject    : Re: The very latest emacs (25.1.50) segfault
  Message-ID : <83a8odmnrc.fsf@gnu.org>
  Date & Time: Sun, 10 Jan 2016 17:56:39 +0200

Eli Zaretskii <eliz@gnu.org> has written:

>> Date: Sun, 10 Jan 2016 13:55:49 +0900
>> From: Masaru Nomiya <nomiya@galaxy.dti.ne.jp>
>> 
>> masaru@linux-uw5l:/tmp/tes/emacs> src/emacs
>> Fatal error 11: Segmentation fault
>> Backtrace:
>> src/emacs[0x4fb622]
>> src/emacs[0x4e3384]
>> src/emacs[0x4fa52e]
>> src/emacs[0x4fa733]
>> src/emacs[0x4fa76a]
>> /lib64/libpthread.so.0(+0xf1f0)[0x7f8fb6d871f0]
>> src/emacs[0x5aeda9]
>> src/emacs[0x5b0aea]

> Can you use the procedure described in the node "Crashing" of the
> Emacs User manual to produce human-readable backtrace with file names
> and line numbers out of this?  Otherwise it's impossible for us to
> interpret this data.

Sorry, but I tried.

masaru@linux-uw5l:/tmp/tes/emacs> src/emacs
Fatal error 11: Segmentation fault
Backtrace:
src/emacs[0x4fb622]
src/emacs[0x4e3384]
src/emacs[0x4fa52e]
src/emacs[0x4fa733]
src/emacs[0x4fa76a]
/lib64/libpthread.so.0(+0xf1f0)[0x7fc21d1481f0]
src/emacs[0x5aeda9]
[...]

(gdb) list *0x5aeda9
0x5aeda9 is in ftfont_shape (lisp.h:856).
851     }
852     
853     INLINE EMACS_INT
854     (XINT) (Lisp_Object a)
855     {
856       return lisp_h_XINT (a);
857     }
858     
859     INLINE EMACS_INT
860     (XFASTINT) (Lisp_Object a)
(gdb)

Is this right?

Thanks,

---
M. Nomiya

Re: The very latest emacs (25.1.50) segfault

[Eli Zaretskii]

> Date: Mon, 11 Jan 2016 10:24:44 +0900
> From: Masaru Nomiya <nomiya@galaxy.dti.ne.jp>
> 
> > Can you use the procedure described in the node "Crashing" of the
> > Emacs User manual to produce human-readable backtrace with file names
> > and line numbers out of this?  Otherwise it's impossible for us to
> > interpret this data.
> 
> Sorry, but I tried.
> 
> masaru@linux-uw5l:/tmp/tes/emacs> src/emacs
> Fatal error 11: Segmentation fault
> Backtrace:
> src/emacs[0x4fb622]
> src/emacs[0x4e3384]
> src/emacs[0x4fa52e]
> src/emacs[0x4fa733]
> src/emacs[0x4fa76a]
> /lib64/libpthread.so.0(+0xf1f0)[0x7fc21d1481f0]
> src/emacs[0x5aeda9]
> [...]
> 
> (gdb) list *0x5aeda9
> 0x5aeda9 is in ftfont_shape (lisp.h:856).
> 851     }
> 852     
> 853     INLINE EMACS_INT
> 854     (XINT) (Lisp_Object a)
> 855     {
> 856       return lisp_h_XINT (a);
> 857     }
> 858     
> 859     INLINE EMACS_INT
> 860     (XFASTINT) (Lisp_Object a)
> (gdb)
> 
> Is this right?

Yes, but I meant the addr2line method described there.  It should
produce more information.

Thanks.

Re: The very latest emacs (25.1.50) segfault

[Masaru Nomiya]

Hello,

Sorry, I've sent DM to Eli.

In the Message; 

  Subject    : Re: The very latest emacs (25.1.50) segfault
  Message-ID : <83wprglr87.fsf@gnu.org>
  Date & Time: Mon, 11 Jan 2016 05:39:20 +0200

Eli Zaretskii <eliz@gnu.org> has written:

>> Date: Mon, 11 Jan 2016 10:24:44 +0900
>> From: Masaru Nomiya <nomiya@galaxy.dti.ne.jp>
[...]
>> (gdb) list *0x5aeda9
>> 0x5aeda9 is in ftfont_shape (lisp.h:856).
>> 851     }
>> 852     
>> 853     INLINE EMACS_INT
>> 854     (XINT) (Lisp_Object a)
>> 855     {
>> 856       return lisp_h_XINT (a);
>> 857     }
>> 858     
>> 859     INLINE EMACS_INT
>> 860     (XFASTINT) (Lisp_Object a)
>> (gdb)
>> 
>> Is this right?

> Yes, but I meant the addr2line method described there.  It should
> produce more information.

I only could get the backtrace.


Program received signal SIGSEGV, Segmentation fault.
ftfont_shape_by_flt (matrix=0x3bd67d8, otf=<optimized out>, ft_face=0x3cbb300, 
    font=0x3bd66e0, lgstring=12801653) at ftfont.c:2598
2598          int c1 = LGLYPH_CHAR (LGSTRING_GLYPH (lgstring, 1));
(gdb) backtrace
#0  ftfont_shape_by_flt (matrix=0x3bd4868, otf=<optimized out>, ft_face=
    0x3d37310, font=0x3bd4770, lgstring=12801653) at ftfont.c:2598
#1  ftfont_shape (lgstring=12801653) at ftfont.c:2690
#2  0x00000000005b0aea in xftfont_shape (lgstring=12801653) at xftfont.c:664
#3  0x00000000005608c5 in Ffont_shape_gstring (gstring=12801653) at font.c:4410
#4  0x0000000000553570 in Ffuncall (nargs=2, args=<optimized out>)
    at eval.c:2693
#5  0x0000000000586235 in exec_byte_code (bytestr=31525964, vector=0, maxdepth=
    62736488, args_template=140737488306080, nargs=2, args=0x2, args@entry=0x0)
    at bytecode.c:880
#6  0x0000000000552fc2 in funcall_lambda (fun=9765533, nargs=nargs@entry=5, 
    arg_vector=arg_vector@entry=0x7fffffff41b8) at eval.c:2921
#7  0x0000000000553383 in Ffuncall (nargs=nargs@entry=6, args=args@entry=
    0x7fffffff41b0) at eval.c:2754
#8  0x0000000000552001 in internal_condition_case_n (bfun=0x5531a0 <Ffuncall>, 
    nargs=nargs@entry=6, args=args@entry=0x7fffffff41b0, 
    handlers=handlers@entry=44448, hfun=hfun@entry=
    0x43b180 <safe_eval_handler>) at eval.c:1389
#9  0x000000000042b766 in safe__call (inhibit_quit=inhibit_quit@entry=false, 
    nargs=nargs@entry=6, func=<optimized out>, ap=ap@entry=0x7fffffff4258)
    at xdisp.c:2555
#10 0x000000000043832f in safe_call (nargs=nargs@entry=6, func=<optimized out>)
    at xdisp.c:2571
#11 0x00000000005a2b0c in autocmp_chars (rule=rule@entry=19429861, 
    charpos=charpos@entry=305, bytepos=322, limit=<optimized out>, limit@entry=
    306, win=win@entry=0x1292a90, face=face@entry=0x3dca4e0, 
    string=string@entry=0) at composite.c:915
#12 0x00000000005a6acb in composition_reseat_it (cmp_it=cmp_it@entry=
    0x7fffffffacb8, charpos=305, bytepos=322, endpos=1, w=0x1292a90, face=
    0x3dca4e0, string=0) at composite.c:1246
#13 0x00000000004419a8 in next_element_from_buffer (it=0x7fffffffa460)
    at xdisp.c:8293
#14 0x000000000043fd1a in get_next_display_element (it=it@entry=0x7fffffffa460)
    at xdisp.c:6893
#15 0x0000000000441be1 in move_it_in_display_line_to (it=it@entry=
    0x7fffffffa460, to_charpos=to_charpos@entry=15588, to_x=to_x@entry=-1, 
    op=op@entry=MOVE_TO_POS) at xdisp.c:8583
#16 0x0000000000443f6c in move_it_to (it=it@entry=0x7fffffffa460, to_charpos=
    15588, to_x=to_x@entry=-1, to_y=1040, to_vpos=to_vpos@entry=-1, 
    op=op@entry=10) at xdisp.c:9174
#17 0x00000000004446b6 in move_it_vertically (it=0x7fffffffa460, 
    dy=<optimized out>) at xdisp.c:9555
#18 0x000000000046fcb9 in Fwindow_end (window=<optimized out>, 
    update=<optimized out>) at window.c:1618
#19 0x0000000000553564 in Ffuncall (nargs=3, args=<optimized out>)
    at eval.c:2696
#20 0x0000000000586235 in exec_byte_code (bytestr=31525964, vector=0, maxdepth=
    62736488, args_template=47, nargs=3, args=0x2, args@entry=0x0)
    at bytecode.c:880
#21 0x0000000000552fc2 in funcall_lambda (fun=28755165, nargs=nargs@entry=0, 
    arg_vector=arg_vector@entry=0x7fffffffb9d0) at eval.c:2921
#22 0x0000000000553383 in Ffuncall (nargs=1, args=0x7fffffffb9c8)
    at eval.c:2754
#23 0x0000000000586235 in exec_byte_code (bytestr=31525964, vector=0, maxdepth=
    62736488, args_template=140737488337344, nargs=1, args=0x2, args@entry=0x0)
    at bytecode.c:880
#24 0x0000000000552fc2 in funcall_lambda (fun=28759853, nargs=nargs@entry=1, 
    arg_vector=arg_vector@entry=0x7fffffffbbb0) at eval.c:2921
#25 0x0000000000553383 in Ffuncall (nargs=2, args=0x7fffffffbba8)
    at eval.c:2754
#26 0x0000000000586235 in exec_byte_code (bytestr=31525964, vector=0, maxdepth=
    62736488, args_template=140737488337824, nargs=2, args=0x2, args@entry=0x0)
    at bytecode.c:880
#27 0x0000000000552fc2 in funcall_lambda (fun=28274245, nargs=nargs@entry=1, 
    arg_vector=arg_vector@entry=0x7fffffffbd70) at eval.c:2921
#28 0x0000000000553383 in Ffuncall (nargs=2, args=0x7fffffffbd68)
    at eval.c:2754
#29 0x0000000000586235 in exec_byte_code (bytestr=31525964, vector=0, maxdepth=
    62736488, args_template=140737488338288, nargs=2, args=0x2, args@entry=0x0)
    at bytecode.c:880
#30 0x0000000000552fc2 in funcall_lambda (fun=28274373, nargs=nargs@entry=1, 
    arg_vector=arg_vector@entry=0x7fffffffbf30) at eval.c:2921
#31 0x0000000000553383 in Ffuncall (nargs=2, args=0x7fffffffbf28)
    at eval.c:2754
#32 0x0000000000586235 in exec_byte_code (bytestr=31525964, vector=0, maxdepth=
    62736488, args_template=25, nargs=2, args=0x2, args@entry=0x0)
    at bytecode.c:880
#33 0x0000000000552fc2 in funcall_lambda (fun=28263613, nargs=nargs@entry=1, 
    arg_vector=arg_vector@entry=0x7fffffffc110) at eval.c:2921
#34 0x0000000000553383 in Ffuncall (nargs=2, args=0x7fffffffc108)
    at eval.c:2754
#35 0x0000000000586235 in exec_byte_code (bytestr=31525964, vector=0, maxdepth=
    62736488, args_template=140737488339200, nargs=2, args=0x2, args@entry=0x0)
    at bytecode.c:880
#36 0x0000000000552fc2 in funcall_lambda (fun=28649917, nargs=nargs@entry=1, 
    arg_vector=arg_vector@entry=0x7fffffffc2e0) at eval.c:2921
#37 0x0000000000553383 in Ffuncall (nargs=2, args=0x7fffffffc2d8)
    at eval.c:2754
#38 0x0000000000586235 in exec_byte_code (bytestr=31525964, vector=0, maxdepth=
    62736488, args_template=140737488339664, nargs=2, args=0x2, args@entry=0x0)
    at bytecode.c:880
#39 0x0000000000552fc2 in funcall_lambda (fun=29624077, nargs=nargs@entry=0, 
    arg_vector=arg_vector@entry=0x7fffffffc4c0) at eval.c:2921
#40 0x0000000000553383 in Ffuncall (nargs=nargs@entry=1, args=args@entry=
    0x7fffffffc4b8) at eval.c:2754
#41 0x0000000000585f48 in bcall0 (f=29624077) at bytecode.c:455
#42 0x000000000055224e in unbind_to (count=<optimized out>, value=0)
    at eval.c:3185
#43 0x000000000058627b in exec_byte_code (bytestr=31525964, vector=0, maxdepth=
    62736488, args_template=140737488340240, nargs=2, args=0x2, args@entry=0x0)
    at bytecode.c:902
#44 0x0000000000552fc2 in funcall_lambda (fun=29624437, nargs=nargs@entry=0, 
    arg_vector=arg_vector@entry=0x7fffffffc6f0) at eval.c:2921
#45 0x0000000000553383 in Ffuncall (nargs=nargs@entry=1, args=args@entry=
    0x7fffffffc6e8) at eval.c:2754
#46 0x0000000000585f48 in bcall0 (f=29624437) at bytecode.c:455
#47 0x000000000055224e in unbind_to (count=<optimized out>, value=0)
    at eval.c:3185
#48 0x000000000058627b in exec_byte_code (bytestr=31525964, vector=0, maxdepth=
    62736488, args_template=140737488340800, nargs=1, args=0x2, args@entry=0x0)
    at bytecode.c:902
#49 0x0000000000552fc2 in funcall_lambda (fun=29624613, nargs=nargs@entry=5, 
    arg_vector=arg_vector@entry=0x7fffffffc930) at eval.c:2921
#50 0x0000000000553383 in Ffuncall (nargs=6, args=0x7fffffffc928)
    at eval.c:2754
#51 0x0000000000586235 in exec_byte_code (bytestr=31525964, vector=0, maxdepth=
    62736488, args_template=176, nargs=6, args=0x2, args@entry=0x0)
    at bytecode.c:880
#52 0x0000000000552fc2 in funcall_lambda (fun=28441469, nargs=nargs@entry=0, 
    arg_vector=arg_vector@entry=0x7fffffffcb20) at eval.c:2921
#53 0x0000000000553383 in Ffuncall (nargs=1, args=0x7fffffffcb18)
    at eval.c:2754
#54 0x0000000000586235 in exec_byte_code (bytestr=31525964, vector=0, maxdepth=
    62736488, args_template=0, nargs=1, args=0x2, args@entry=0x0)
    at bytecode.c:880
#55 0x0000000000552fc2 in funcall_lambda (fun=28506637, nargs=nargs@entry=1, 
    arg_vector=arg_vector@entry=0x7fffffffcdb0) at eval.c:2921
#56 0x0000000000553383 in Ffuncall (nargs=nargs@entry=2, args=args@entry=
    0x7fffffffcda8) at eval.c:2754
#57 0x000000000054f33a in Ffuncall_interactively (nargs=2, args=0x7fffffffcda8)
    at callint.c:248
#58 0x000000000055347a in Ffuncall (nargs=nargs@entry=3, args=args@entry=
    0x7fffffffcda0) at eval.c:2673
#59 0x000000000054fdd7 in Fcall_interactively (function=<optimized out>, 
    record_flag=<optimized out>, keys=<optimized out>) at callint.c:836
#60 0x0000000000553554 in Ffuncall (nargs=4, args=<optimized out>)
    at eval.c:2700
#61 0x0000000000586235 in exec_byte_code (bytestr=31525964, vector=0, maxdepth=
    62736488, args_template=140737488343040, nargs=4, args=0x2, args@entry=0x4)
    at bytecode.c:880
#62 0x00000000005530f6 in funcall_lambda (fun=9583552, nargs=nargs@entry=1, 
    arg_vector=0x4, arg_vector@entry=0x7fffffffd178) at eval.c:2855
#63 0x0000000000553383 in Ffuncall (nargs=nargs@entry=2, args=args@entry=
    0x7fffffffd170) at eval.c:2754
#64 0x000000000055367a in call1 (fn=fn@entry=14784, arg1=<optimized out>)
    at eval.c:2552
#65 0x00000000004f1470 in command_loop_1 () at keyboard.c:1458
#66 0x0000000000551e6d in internal_condition_case (bfun=bfun@entry=
    0x4f1080 <command_loop_1>, handlers=handlers@entry=19056, hfun=hfun@entry=
    0x4e8100 <cmd_error>) at eval.c:1309
#67 0x00000000004e388c in command_loop_2 (ignore=ignore@entry=0)
    at keyboard.c:1087
#68 0x0000000000551e1b in internal_catch (tag=tag@entry=45840, func=func@entry=
    0x4e3870 <command_loop_2>, arg=arg@entry=0) at eval.c:1074
#69 0x00000000004e3847 in command_loop () at keyboard.c:1066
#70 0x00000000004e7d38 in recursive_edit_1 () at keyboard.c:672
#71 0x00000000004e8055 in Frecursive_edit () at keyboard.c:743
#72 0x0000000000415b53 in main (argc=1, argv=0x7fffffffd528) at emacs.c:1667

--
M. Nomiya

Re: The very latest emacs (25.1.50) segfault

[Masaru Nomiya]

Hello,

In the Message; 

  Subject    : Re: The very latest emacs (25.1.50) segfault
  Message-ID : <87pox8ww60.wl%nomiya@galaxy.dti.ne.jp>
  Date & Time: Mon, 11 Jan 2016 13:57:11 +0900

[MN] == Masaru Nomiya <nomiya@galaxy.dti.ne.jp> has written:

MN> Hello,

MN> Sorry, I've sent DM to Eli.

MN> In the Message; 

MN>   Subject    : Re: The very latest emacs (25.1.50) segfault
MN>   Message-ID : <83wprglr87.fsf@gnu.org>
MN>   Date & Time: Mon, 11 Jan 2016 05:39:20 +0200

MN> Eli Zaretskii <eliz@gnu.org> has written:

MN> I only could get the backtrace.

The result of;

masaru@linux-uw5l:/tmp/tes/emacs> sed -n 's/.*\[\(.*\)]$/\1/p' backtrace | addr2line -C -f -i -p -e src/emacs


??
??:0
??
??:0
??
??:0
??
??:0

Thanks,
--
M. Nomiya

Re: The very latest emacs (25.1.50) segfault

[Eli Zaretskii]

> Date: Mon, 11 Jan 2016 13:57:11 +0900
> From: Masaru Nomiya <nomiya@galaxy.dti.ne.jp>
> 
> Program received signal SIGSEGV, Segmentation fault.
> ftfont_shape_by_flt (matrix=0x3bd67d8, otf=<optimized out>, ft_face=0x3cbb300, 
>     font=0x3bd66e0, lgstring=12801653) at ftfont.c:2598
> 2598          int c1 = LGLYPH_CHAR (LGSTRING_GLYPH (lgstring, 1));
> (gdb) backtrace
> #0  ftfont_shape_by_flt (matrix=0x3bd4868, otf=<optimized out>, ft_face=
>     0x3d37310, font=0x3bd4770, lgstring=12801653) at ftfont.c:2598
> #1  ftfont_shape (lgstring=12801653) at ftfont.c:2690
> #2  0x00000000005b0aea in xftfont_shape (lgstring=12801653) at xftfont.c:664
> #3  0x00000000005608c5 in Ffont_shape_gstring (gstring=12801653) at font.c:4410
> #4  0x0000000000553570 in Ffuncall (nargs=2, args=<optimized out>)
>     at eval.c:2693
> #5  0x0000000000586235 in exec_byte_code (bytestr=31525964, vector=0, maxdepth=
>     62736488, args_template=140737488306080, nargs=2, args=0x2, args@entry=0x0)
>     at bytecode.c:880
> #6  0x0000000000552fc2 in funcall_lambda (fun=9765533, nargs=nargs@entry=5, 
>     arg_vector=arg_vector@entry=0x7fffffff41b8) at eval.c:2921
> #7  0x0000000000553383 in Ffuncall (nargs=nargs@entry=6, args=args@entry=
>     0x7fffffff41b0) at eval.c:2754
> #8  0x0000000000552001 in internal_condition_case_n (bfun=0x5531a0 <Ffuncall>, 
>     nargs=nargs@entry=6, args=args@entry=0x7fffffff41b0, 
>     handlers=handlers@entry=44448, hfun=hfun@entry=
>     0x43b180 <safe_eval_handler>) at eval.c:1389
> #9  0x000000000042b766 in safe__call (inhibit_quit=inhibit_quit@entry=false, 
>     nargs=nargs@entry=6, func=<optimized out>, ap=ap@entry=0x7fffffff4258)
>     at xdisp.c:2555
> #10 0x000000000043832f in safe_call (nargs=nargs@entry=6, func=<optimized out>)
>     at xdisp.c:2571
> #11 0x00000000005a2b0c in autocmp_chars (rule=rule@entry=19429861, 
>     charpos=charpos@entry=305, bytepos=322, limit=<optimized out>, limit@entry=
>     306, win=win@entry=0x1292a90, face=face@entry=0x3dca4e0, 
>     string=string@entry=0) at composite.c:915
> #12 0x00000000005a6acb in composition_reseat_it (cmp_it=cmp_it@entry=
>     0x7fffffffacb8, charpos=305, bytepos=322, endpos=1, w=0x1292a90, face=
>     0x3dca4e0, string=0) at composite.c:1246
> #13 0x00000000004419a8 in next_element_from_buffer (it=0x7fffffffa460)
>     at xdisp.c:8293
> #14 0x000000000043fd1a in get_next_display_element (it=it@entry=0x7fffffffa460)
>     at xdisp.c:6893
> #15 0x0000000000441be1 in move_it_in_display_line_to (it=it@entry=
>     0x7fffffffa460, to_charpos=to_charpos@entry=15588, to_x=to_x@entry=-1, 
>     op=op@entry=MOVE_TO_POS) at xdisp.c:8583
> #16 0x0000000000443f6c in move_it_to (it=it@entry=0x7fffffffa460, to_charpos=
>     15588, to_x=to_x@entry=-1, to_y=1040, to_vpos=to_vpos@entry=-1, 
>     op=op@entry=10) at xdisp.c:9174
> #17 0x00000000004446b6 in move_it_vertically (it=0x7fffffffa460, 
>     dy=<optimized out>) at xdisp.c:9555
> #18 0x000000000046fcb9 in Fwindow_end (window=<optimized out>, 

Thanks.  Does this happen right when you start Emacs?  Does this
happen if you start it as "emacs -Q"?

This looks like a crash in displaying some complex script, so can you
tell what text was supposed to be displayed?

Also, if this started happening lately, can you bisect to find the
commit which exposed this problem?

Thanks.

Re: The very latest emacs (25.1.50) segfault

[野宮 賢 / NOMIYA Masaru]

Hello,

In the Message; 

  Subject    : Re: The very latest emacs (25.1.50) segfault
  Message-ID : <83bn8skm7j.fsf@gnu.org>
  Date & Time: Mon, 11 Jan 2016 20:25:20 +0200

Eli Zaretskii <eliz@gnu.org> has written:

[...]
> Thanks.  Does this happen right when you start Emacs?  Does this
> happen if you start it as "emacs -Q"?

No, after startng MUA (=Wanderlust) in the Emacs, I get.
When I try to open the specific mail folder of Wanderlust, Emacs
always crashes.

> This looks like a crash in displaying some complex script, so can you
> tell what text was supposed to be displayed?

Just an e-mail, but I can't find out the problematic e-mail(s).

> Also, if this started happening lately, can you bisect to find the
> commit which exposed this problem?

No, I can't.
But, since Jan 3rd JST, I met this problem.

Thanks,

--
M. Nomiya

Re: The very latest emacs (25.1.50) segfault

[K. Handa]

In article <83bn8skm7j.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > Date: Mon, 11 Jan 2016 13:57:11 +0900
> > From: Masaru Nomiya <nomiya@galaxy.dti.ne.jp>
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > ftfont_shape_by_flt (matrix=0x3bd67d8, otf=<optimized out>, ft_face=0x3cbb300, 
> >     font=0x3bd66e0, lgstring=12801653) at ftfont.c:2598
> > 2598          int c1 = LGLYPH_CHAR (LGSTRING_GLYPH (lgstring, 1));
> > (gdb) backtrace
> > #0  ftfont_shape_by_flt (matrix=0x3bd4868, otf=<optimized out>, ft_face=
> >     0x3d37310, font=0x3bd4770, lgstring=12801653) at ftfont.c:2598
> > #1  ftfont_shape (lgstring=12801653) at ftfont.c:2690
> > #2  0x00000000005b0aea in xftfont_shape (lgstring=12801653) at xftfont.c:664
> > #3  0x00000000005608c5 in Ffont_shape_gstring (gstring=12801653) at font.c:4410
[...]
> Thanks.  Does this happen right when you start Emacs?  Does this
> happen if you start it as "emacs -Q"?

> This looks like a crash in displaying some complex script, so can you
> tell what text was supposed to be displayed?

> Also, if this started happening lately, can you bisect to find the
> commit which exposed this problem?

There's a possibility that my recent change is a culprit.  Please try
to revert this change.

commit 536f48e9a2251b9e654ea974bd90ff2f40218753
Author: K. Handa <handa@gnu.org>
Date:   Sat Jan 2 16:36:21 2016 +0900

    support rendering of wider range of combinging characters by ftfont backend
    
    * lisp/language/hebrew.el (hebrew-shape-gstring): If the font backend
    supports rendering of combining characters, call
    font-shape-gstring.
    
    * src/font.c (Ffont_get): Handle `combining-capability' property.
    (syms_of_font): New symbol ":combining-capability'.
    
    * src/font.h (struct font_driver): New member combining_capability.
    
    * src/ftfont.c: Include "category.h".
    (ftfont_driver): Initialize combining_capability to
    ftfont_combining_capability.
    (ftfont_shape_by_flt): If OTF is null, try to find a suitable
    FLT in advance.
    (ftfont_combining_capability): New function.

---
K. Handa
handa@gnu.org

Re: The very latest emacs (25.1.50) segfault

[K. Handa]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

In article <87d1t6l389.wl%nomiya@galaxy.dti.ne.jp>, 野宮　賢 / NOMIYA Masaru <nomiya@galaxy.dti.ne.jp> writes:

[...]
> > There's a possibility that my recent change is a culprit.  Please try
> > to revert this change.

> > commit 536f48e9a2251b9e654ea974bd90ff2f40218753
> > Author: K. Handa <handa@gnu.org>
> > Date:   Sat Jan 2 16:36:21 2016 +0900
[...]
> I got from git head;

> -rw-r--r-- 1 masaru users 156108  1月 13 08:56 src/font.c
> -rw-r--r-- 1 masaru users  32767  1月 13 08:56 src/font.h
> -rw-r--r-- 1 masaru users  76243  1月 13 08:56 src/ftfont.c
> -rw-r--r-- 1 masaru users   9843  1月 13 08:56 lisp/language/hebrew.el

> Maybe, these are reverted files.

No, they are the latest files.  I'll attach old files ((i.e. the
versions before my change).

> I compiled, but I got the same result as before.

Please configure your emacs source with the following command, and
re-compile.

% CFLAGS='-O0 -g3' ./configure --enable-checking='yes,glyphs' --enable-check-lisp-object-type

Then the debugger's backtrace command will show more useful information.

---
K. Handa
handa@gnu.org


[-- Attachment #2: old.tar.gz --]
[-- Type: application/octet-stream, Size: 69289 bytes --]

Re: The very latest emacs (25.1.50) segfault

[Masaru Nomiya]

Hello,

In the Message; 

  Subject    : Re: The very latest emacs (25.1.50) segfault
  Message-ID : <87lh7t57ud.fsf@gnu.org>
  Date & Time: Thu, 14 Jan 2016 09:21:30 +0900

handa@gnu.org (K. Handa) has written:

[...]
> > Maybe, these are reverted files.

> No, they are the latest files.  I'll attach old files ((i.e. the
> versions before my change).

Ah, I see.

> > I compiled, but I got the same result as before.

> Please configure your emacs source with the following command, and
> re-compile.

> % CFLAGS='-O0 -g3' ./configure --enable-checking='yes,glyphs' --enable-check-lisp-object-type

> Then the debugger's backtrace command will show more useful information.

Thank you so much, indeed.

Anyway, I did;

Program received signal SIGABRT, Aborted.
0x00007ffff16bc0cb in raise () from /lib64/libpthread.so.0
#0  0x00007ffff16bc0cb in raise () from /lib64/libpthread.so.0
#1  0x00000000005810fe in terminate_due_to_signal (sig=6, backtrace_limit=
    2147483647) at emacs.c:401
#2  0x00000000006117dc in die (msg=0x73e98e "VECTORLIKEP (a)", file=
    0x73e940 "lisp.h", line=1024) at alloc.c:7063
#3  0x000000000057b3ad in XVECTOR (a=...) at lisp.h:1024
#4  0x000000000057c054 in AREF (array=..., idx=2) at lisp.h:1542
#5  0x00000000006c62e3 in ftfont_shape_by_flt (lgstring=..., font=0x3d0a098, 
    ft_face=0x3f6f5a0, otf=0x0, matrix=0x3d0a190) at ftfont.c:2598
#6  0x00000000006c6a82 in ftfont_shape (lgstring=...) at ftfont.c:2690
#7  0x00000000006c8dba in xftfont_shape (lgstring=...) at xftfont.c:664
#8  0x0000000000658ba0 in Ffont_shape_gstring (gstring=...) at font.c:4410
#9  0x00000000006361c3 in Ffuncall (nargs=2, args=0x7ffffffee1e8)
    at eval.c:2693
#10 0x000000000068245e in exec_byte_code (bytestr=..., vector=..., maxdepth=
    ..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
#11 0x0000000000637053 in funcall_lambda (fun=..., nargs=5, arg_vector=
    0xabb6cd <pure+1076749>) at eval.c:2921
#12 0x000000000063642d in Ffuncall (nargs=6, args=0x7ffffffeead0)
    at eval.c:2742
#13 0x00000000006326e4 in internal_condition_case_n (bfun=0x635de7 <Ffuncall>, 
    nargs=6, args=0x7ffffffeead0, handlers=..., hfun=
    0x4474da <safe_eval_handler>) at eval.c:1389
#14 0x000000000044777b in safe__call (inhibit_quit=false, nargs=6, func=..., 
    ap=0x7ffffffeebb8) at xdisp.c:2555
#15 0x000000000044786e in safe_call (nargs=6, func=...) at xdisp.c:2571
#16 0x00000000006b3a97 in autocmp_chars (rule=..., charpos=305, bytepos=322, 
    limit=306, win=0x149b670, face=0x42032d0, string=...) at composite.c:915
#17 0x00000000006b5268 in composition_reseat_it (cmp_it=0x7fffffff5728, 
    charpos=305, bytepos=322, endpos=1, w=0x149b670, face=0x42032d0, string=
    ...) at composite.c:1246
#18 0x000000000045962b in next_element_from_buffer (it=0x7fffffff4ed0)
    at xdisp.c:8297
#19 0x0000000000455697 in get_next_display_element (it=0x7fffffff4ed0)
    at xdisp.c:6897
#20 0x000000000045a087 in move_it_in_display_line_to (it=0x7fffffff4ed0, 
    to_charpos=16875, to_x=-1, op=MOVE_TO_POS) at xdisp.c:8587
#21 0x000000000045d02c in move_it_to (it=0x7fffffff4ed0, to_charpos=16875, 
    to_x=-1, to_y=1040, to_vpos=-1, op=10) at xdisp.c:9178
#22 0x000000000045e237 in move_it_vertically (it=0x7fffffff4ed0, dy=1040)
    at xdisp.c:9559
#23 0x00000000004bf6d4 in Fwindow_end (window=..., update=...) at window.c:1618
#24 0x00000000006361f0 in Ffuncall (nargs=3, args=0x7fffffff62f0)
    at eval.c:2696
#25 0x000000000068245e in exec_byte_code (bytestr=..., vector=..., maxdepth=
    ..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
#26 0x0000000000637053 in funcall_lambda (fun=..., nargs=0, arg_vector=
    0x1dc017d) at eval.c:2921
#27 0x000000000063642d in Ffuncall (nargs=1, args=0x7fffffff6b68)
    at eval.c:2742
#28 0x000000000068245e in exec_byte_code (bytestr=..., vector=..., maxdepth=
    ..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
#29 0x0000000000637053 in funcall_lambda (fun=..., nargs=1, arg_vector=
    0x1e65c6d) at eval.c:2921
#30 0x000000000063642d in Ffuncall (nargs=2, args=0x7fffffff73f8)
    at eval.c:2742
#31 0x000000000068245e in exec_byte_code (bytestr=..., vector=..., maxdepth=
    ..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
#32 0x0000000000637053 in funcall_lambda (fun=..., nargs=1, arg_vector=
    0x1e62ea5) at eval.c:2921
#33 0x000000000063642d in Ffuncall (nargs=2, args=0x7fffffff7c68)
    at eval.c:2742
#34 0x000000000068245e in exec_byte_code (bytestr=..., vector=..., maxdepth=
    ..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
#35 0x0000000000637053 in funcall_lambda (fun=..., nargs=1, arg_vector=
    0x1e62efd) at eval.c:2921
#36 0x000000000063642d in Ffuncall (nargs=2, args=0x7fffffff84d8)
    at eval.c:2742
#37 0x000000000068245e in exec_byte_code (bytestr=..., vector=..., maxdepth=
    ..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
#38 0x0000000000637053 in funcall_lambda (fun=..., nargs=1, arg_vector=
    0x1e06fa5) at eval.c:2921
#39 0x000000000063642d in Ffuncall (nargs=2, args=0x7fffffff8d68)
    at eval.c:2742
#40 0x000000000068245e in exec_byte_code (bytestr=..., vector=..., maxdepth=
    ..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
#41 0x0000000000637053 in funcall_lambda (fun=..., nargs=1, arg_vector=
    0x1d37ad5) at eval.c:2921
#42 0x000000000063642d in Ffuncall (nargs=2, args=0x7fffffff95e8)
    at eval.c:2742
#43 0x000000000068245e in exec_byte_code (bytestr=..., vector=..., maxdepth=
    ..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
#44 0x0000000000637053 in funcall_lambda (fun=..., nargs=0, arg_vector=
    0x1e5533d) at eval.c:2921
#45 0x000000000063642d in Ffuncall (nargs=1, args=0x7fffffff9e70)
    at eval.c:2742
#46 0x00000000006815f7 in bcall0 (f=...) at bytecode.c:455
#47 0x0000000000637945 in unbind_to (count=40, value=...) at eval.c:3182
#48 0x000000000068251f in exec_byte_code (bytestr=..., vector=..., maxdepth=
    ..., args_template=..., nargs=0, args=0x0) at bytecode.c:902
#49 0x0000000000637053 in funcall_lambda (fun=..., nargs=0, arg_vector=
    0x1e5557d) at eval.c:2921
#50 0x000000000063642d in Ffuncall (nargs=1, args=0x7fffffffa790)
    at eval.c:2742
#51 0x00000000006815f7 in bcall0 (f=...) at bytecode.c:455
#52 0x0000000000637945 in unbind_to (count=39, value=...) at eval.c:3182
#53 0x000000000068251f in exec_byte_code (bytestr=..., vector=..., maxdepth=
    ..., args_template=..., nargs=0, args=0x0) at bytecode.c:902
#54 0x0000000000637053 in funcall_lambda (fun=..., nargs=5, arg_vector=
    0x1e5e385) at eval.c:2921
#55 0x000000000063642d in Ffuncall (nargs=6, args=0x7fffffffb0c8)
    at eval.c:2742
#56 0x000000000068245e in exec_byte_code (bytestr=..., vector=..., maxdepth=
    ..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
#57 0x0000000000637053 in funcall_lambda (fun=..., nargs=0, arg_vector=
    0x1d83565) at eval.c:2921
#58 0x000000000063642d in Ffuncall (nargs=1, args=0x7fffffffb968)
    at eval.c:2742
#59 0x000000000068245e in exec_byte_code (bytestr=..., vector=..., maxdepth=
    ..., args_template=..., nargs=0, args=0x0) at bytecode.c:880
#60 0x0000000000637053 in funcall_lambda (fun=..., nargs=1, arg_vector=
    0x1d8aec5) at eval.c:2921
#61 0x000000000063642d in Ffuncall (nargs=2, args=0x7fffffffc2f8)
    at eval.c:2742
#62 0x000000000062c31e in Ffuncall_interactively (nargs=2, args=0x7fffffffc2f8)
    at callint.c:248
#63 0x000000000063608b in Ffuncall (nargs=3, args=0x7fffffffc2f0)
    at eval.c:2673
#64 0x000000000062e893 in Fcall_interactively (function=..., record_flag=..., 
    keys=...) at callint.c:836
#65 0x0000000000636228 in Ffuncall (nargs=4, args=0x7fffffffc798)
    at eval.c:2700
#66 0x000000000068245e in exec_byte_code (bytestr=..., vector=..., maxdepth=
    ..., args_template=..., nargs=1, args=0x7fffffffd050) at bytecode.c:880
#67 0x0000000000636bac in funcall_lambda (fun=..., nargs=1, arg_vector=
    0x7fffffffd048) at eval.c:2855
#68 0x000000000063642d in Ffuncall (nargs=2, args=0x7fffffffd040)
    at eval.c:2742
#69 0x0000000000635b68 in call1 (fn=..., arg1=...) at eval.c:2552
#70 0x0000000000586192 in command_loop_1 () at keyboard.c:1458
#71 0x00000000006324f8 in internal_condition_case (bfun=
    0x585998 <command_loop_1>, handlers=..., hfun=0x585007 <cmd_error>)
    at eval.c:1309
#72 0x00000000005855c6 in command_loop_2 (ignore=...) at keyboard.c:1087
#73 0x0000000000631a9a in internal_catch (tag=..., func=
    0x58559d <command_loop_2>, arg=...) at eval.c:1074
#74 0x0000000000585566 in command_loop () at keyboard.c:1066
#75 0x0000000000584afe in recursive_edit_1 () at keyboard.c:672
#76 0x0000000000584cfa in Frecursive_edit () at keyboard.c:743
#77 0x0000000000582ae4 in main (argc=1, argv=0x7fffffffd528) at emacs.c:1667

Thanks,

---
M. Nomiya

Re: The very latest emacs (25.1.50) segfault

[Masaru Nomiya]

Hello,

In the Message; 

  Subject    : Re: The very latest emacs (25.1.50) segfault
  Message-ID : <87lh7t57ud.fsf@gnu.org>
  Date & Time: Thu, 14 Jan 2016 09:21:30 +0900

handa@gnu.org (K. Handa) has written:

[...]
> > -rw-r--r-- 1 masaru users 156108  1月 13 08:56 src/font.c
> > -rw-r--r-- 1 masaru users  32767  1月 13 08:56 src/font.h
> > -rw-r--r-- 1 masaru users  76243  1月 13 08:56 src/ftfont.c
> > -rw-r--r-- 1 masaru users   9843  1月 13 08:56 lisp/language/hebrew.el

> > Maybe, these are reverted files.

> No, they are the latest files.  I'll attach old files ((i.e. the
> versions before my change).

[...]
[2 old.tar.gz <application/octet-stream (base64)>]

With these files, the segfault problem is solved.

Thanks,

---
M. Nomiya

Re: The very latest emacs (25.1.50) segfault

[K. Handa]

In article <87r3hlsz99.wl%nomiya@galaxy.dti.ne.jp>, Masaru Nomiya <nomiya@galaxy.dti.ne.jp> writes:

> Program received signal SIGABRT, Aborted.
> 0x00007ffff16bc0cb in raise () from /lib64/libpthread.so.0
> #0  0x00007ffff16bc0cb in raise () from /lib64/libpthread.so.0
> #1  0x00000000005810fe in terminate_due_to_signal (sig=6, backtrace_limit=
>     2147483647) at emacs.c:401
> #2  0x00000000006117dc in die (msg=0x73e98e "VECTORLIKEP (a)", file=
>     0x73e940 "lisp.h", line=1024) at alloc.c:7063
> #3  0x000000000057b3ad in XVECTOR (a=...) at lisp.h:1024
> #4  0x000000000057c054 in AREF (array=..., idx=2) at lisp.h:1542
> #5  0x00000000006c62e3 in ftfont_shape_by_flt (lgstring=..., font=0x3d0a098, 
>     ft_face=0x3f6f5a0, otf=0x0, matrix=0x3d0a190) at ftfont.c:2598

In article <87si20inuz.wl%nomiya@galaxy.dti.ne.jp>, Masaru Nomiya <nomiya@galaxy.dti.ne.jp> writes:

> [2 old.tar.gz <application/octet-stream (base64)>]

> With these files, the segfault problem is solved.

Thank you for the info.  I've just installed a fix.  Please try the
latest trunk code.

---
K. Handa
handa@gnu.org

Re: The very latest emacs (25.1.50) segfault

[Masaru Nomiya]

Hello,

In the Message; 

  Subject    : Re: The very latest emacs (25.1.50) segfault
  Message-ID : <87si2071r1.fsf@gnu.org>
  Date & Time: Thu, 14 Jan 2016 22:02:26 +0900

handa@gnu.org (K. Handa) has written:

> In article <87r3hlsz99.wl%nomiya@galaxy.dti.ne.jp>, Masaru Nomiya <nomiya@galaxy.dti.ne.jp> writes:

> > Program received signal SIGABRT, Aborted.
> > 0x00007ffff16bc0cb in raise () from /lib64/libpthread.so.0
> > #0  0x00007ffff16bc0cb in raise () from /lib64/libpthread.so.0
> > #1  0x00000000005810fe in terminate_due_to_signal (sig=6, backtrace_limit=
> >     2147483647) at emacs.c:401
> > #2  0x00000000006117dc in die (msg=0x73e98e "VECTORLIKEP (a)", file=
> >     0x73e940 "lisp.h", line=1024) at alloc.c:7063
> > #3  0x000000000057b3ad in XVECTOR (a=...) at lisp.h:1024
> > #4  0x000000000057c054 in AREF (array=..., idx=2) at lisp.h:1542
> > #5  0x00000000006c62e3 in ftfont_shape_by_flt (lgstring=..., font=0x3d0a098, 
> >     ft_face=0x3f6f5a0, otf=0x0, matrix=0x3d0a190) at ftfont.c:2598

> In article <87si20inuz.wl%nomiya@galaxy.dti.ne.jp>, Masaru Nomiya <nomiya@galaxy.dti.ne.jp> writes:

> > [2 old.tar.gz <application/octet-stream (base64)>]

> > With these files, the segfault problem is solved.

> Thank you for the info.  I've just installed a fix.  Please try the
> latest trunk code.

Thanks a lot.

Regards,

---
M. Nomiya

Re: The very latest emacs (25.1.50) segfault

[K. Handa]

In article <87y4br1ly7.wl%nomiya@galaxy.dti.ne.jp>, Masaru Nomiya <nomiya@galaxy.dti.ne.jp> writes:

> > Thank you for the info.  I've just installed a fix.  Please try the
> > latest trunk code.

> Thanks a lot.

Does it mean that the segfault does not occur with the latest code?

---
K. Handa
handa@gnu.org

Re: The very latest emacs (25.1.50) segfault

[Masaru Nomiya]

Hello,

In the Message; 

  Subject    : Re: The very latest emacs (25.1.50) segfault
  Message-ID : <87bn8g70mw.fsf@gnu.org>
  Date & Time: Thu, 21 Jan 2016 00:04:39 +0900

handa@gnu.org (K. Handa) has written:

> In article <87y4br1ly7.wl%nomiya@galaxy.dti.ne.jp>, Masaru Nomiya <nomiya@galaxy.dti.ne.jp> writes:

> > > Thank you for the info.  I've just installed a fix.  Please try the
> > > latest trunk code.

> > Thanks a lot.

> Does it mean that the segfault does not occur with the latest code?

No, it doesn't.

Thanks,

---
M. Nomiya

Re: The very latest emacs (25.1.50) segfault

[Masaru Nomiya]

Hello,

In the Message; 

  Subject    : Re: The very latest emacs (25.1.50) segfault
  Message-ID : <87powvyfvt.wl%nomiya@galaxy.dti.ne.jp>
  Date & Time: Thu, 21 Jan 2016 08:45:26 +0900

Masaru Nomiya <nomiya@galaxy.dti.ne.jp> has written:

> Hello,

> In the Message; 

>   Subject    : Re: The very latest emacs (25.1.50) segfault
>   Message-ID : <87bn8g70mw.fsf@gnu.org>
>   Date & Time: Thu, 21 Jan 2016 00:04:39 +0900

> handa@gnu.org (K. Handa) has written:

> > In article <87y4br1ly7.wl%nomiya@galaxy.dti.ne.jp>, Masaru Nomiya <nomiya@galaxy.dti.ne.jp> writes:

> > > > Thank you for the info.  I've just installed a fix.  Please try the
> > > > latest trunk code.

> > > Thanks a lot.

> > Does it mean that the segfault does not occur with the latest code?

> No, it doesn't.

That is, my segfault problem was solved with Handa-san's code.
Now, Emacs works fine for me.

---
M. Nomiya

Re: The very latest emacs (25.1.50) segfault

[K. Handa]

In article <87twm6bi7w.wl%nomiya@galaxy.dti.ne.jp>, Masaru Nomiya <nomiya@galaxy.dti.ne.jp> writes:
[...]
> That is, my segfault problem was solved with Handa-san's code.
> Now, Emacs works fine for me.

Thank you for clarifying that.

---
K. Handa
handa@gnu.org