* The very latest emacs (25.1.50) segfault @ 2016-01-10 4:55 Masaru Nomiya 2016-01-10 15:56 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Masaru Nomiya @ 2016-01-10 4:55 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-10 4:55 The very latest emacs (25.1.50) segfault Masaru Nomiya @ 2016-01-10 15:56 ` Eli Zaretskii 2016-01-11 1:24 ` Masaru Nomiya 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2016-01-10 15:56 UTC (permalink / raw) To: Masaru Nomiya; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-10 15:56 ` Eli Zaretskii @ 2016-01-11 1:24 ` Masaru Nomiya 2016-01-11 3:39 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Masaru Nomiya @ 2016-01-11 1:24 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-11 1:24 ` Masaru Nomiya @ 2016-01-11 3:39 ` Eli Zaretskii 2016-01-11 4:57 ` Masaru Nomiya 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2016-01-11 3:39 UTC (permalink / raw) To: Masaru Nomiya; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-11 3:39 ` Eli Zaretskii @ 2016-01-11 4:57 ` Masaru Nomiya 2016-01-11 5:23 ` Masaru Nomiya 2016-01-11 18:25 ` Eli Zaretskii 0 siblings, 2 replies; 18+ messages in thread From: Masaru Nomiya @ 2016-01-11 4:57 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-11 4:57 ` Masaru Nomiya @ 2016-01-11 5:23 ` Masaru Nomiya 2016-01-11 18:25 ` Eli Zaretskii 1 sibling, 0 replies; 18+ messages in thread From: Masaru Nomiya @ 2016-01-11 5:23 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-11 4:57 ` Masaru Nomiya 2016-01-11 5:23 ` Masaru Nomiya @ 2016-01-11 18:25 ` Eli Zaretskii 2016-01-12 9:21 ` 野宮 賢 / NOMIYA Masaru 2016-01-12 20:24 ` K. Handa 1 sibling, 2 replies; 18+ messages in thread From: Eli Zaretskii @ 2016-01-11 18:25 UTC (permalink / raw) To: Masaru Nomiya; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-11 18:25 ` Eli Zaretskii @ 2016-01-12 9:21 ` 野宮 賢 / NOMIYA Masaru 2016-01-12 20:24 ` K. Handa 1 sibling, 0 replies; 18+ messages in thread From: 野宮 賢 / NOMIYA Masaru @ 2016-01-12 9:21 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-11 18:25 ` Eli Zaretskii 2016-01-12 9:21 ` 野宮 賢 / NOMIYA Masaru @ 2016-01-12 20:24 ` K. Handa 1 sibling, 0 replies; 18+ messages in thread From: K. Handa @ 2016-01-12 20:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: nomiya, emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <87d1t6l389.wl%nomiya@galaxy.dti.ne.jp>]
* Re: The very latest emacs (25.1.50) segfault [not found] <87d1t6l389.wl%nomiya@galaxy.dti.ne.jp> @ 2016-01-14 0:21 ` K. Handa 2016-01-14 1:53 ` Masaru Nomiya 2016-01-14 8:09 ` Masaru Nomiya 0 siblings, 2 replies; 18+ messages in thread From: K. Handa @ 2016-01-14 0:21 UTC (permalink / raw) To: 野宮 賢 / NOMIYA Masaru; +Cc: handa, eliz, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-14 0:21 ` K. Handa @ 2016-01-14 1:53 ` Masaru Nomiya 2016-01-14 13:02 ` K. Handa 2016-01-14 8:09 ` Masaru Nomiya 1 sibling, 1 reply; 18+ messages in thread From: Masaru Nomiya @ 2016-01-14 1:53 UTC (permalink / raw) To: handa; +Cc: eliz, emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-14 1:53 ` Masaru Nomiya @ 2016-01-14 13:02 ` K. Handa 2016-01-15 4:54 ` Masaru Nomiya 0 siblings, 1 reply; 18+ messages in thread From: K. Handa @ 2016-01-14 13:02 UTC (permalink / raw) To: Masaru Nomiya; +Cc: eliz, emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-14 13:02 ` K. Handa @ 2016-01-15 4:54 ` Masaru Nomiya 2016-01-20 15:04 ` K. Handa 0 siblings, 1 reply; 18+ messages in thread From: Masaru Nomiya @ 2016-01-15 4:54 UTC (permalink / raw) To: handa; +Cc: eliz, emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-15 4:54 ` Masaru Nomiya @ 2016-01-20 15:04 ` K. Handa 2016-01-20 23:45 ` Masaru Nomiya 0 siblings, 1 reply; 18+ messages in thread From: K. Handa @ 2016-01-20 15:04 UTC (permalink / raw) To: Masaru Nomiya; +Cc: eliz, emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-20 15:04 ` K. Handa @ 2016-01-20 23:45 ` Masaru Nomiya 2016-01-21 23:55 ` Masaru Nomiya 0 siblings, 1 reply; 18+ messages in thread From: Masaru Nomiya @ 2016-01-20 23:45 UTC (permalink / raw) To: handa; +Cc: eliz, emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-20 23:45 ` Masaru Nomiya @ 2016-01-21 23:55 ` Masaru Nomiya 2016-01-22 12:48 ` K. Handa 0 siblings, 1 reply; 18+ messages in thread From: Masaru Nomiya @ 2016-01-21 23:55 UTC (permalink / raw) To: handa; +Cc: eliz, emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-21 23:55 ` Masaru Nomiya @ 2016-01-22 12:48 ` K. Handa 0 siblings, 0 replies; 18+ messages in thread From: K. Handa @ 2016-01-22 12:48 UTC (permalink / raw) To: Masaru Nomiya; +Cc: eliz, emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: The very latest emacs (25.1.50) segfault 2016-01-14 0:21 ` K. Handa 2016-01-14 1:53 ` Masaru Nomiya @ 2016-01-14 8:09 ` Masaru Nomiya 1 sibling, 0 replies; 18+ messages in thread From: Masaru Nomiya @ 2016-01-14 8:09 UTC (permalink / raw) To: handa; +Cc: eliz, emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2016-01-22 12:48 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-01-10 4:55 The very latest emacs (25.1.50) segfault Masaru Nomiya 2016-01-10 15:56 ` Eli Zaretskii 2016-01-11 1:24 ` Masaru Nomiya 2016-01-11 3:39 ` Eli Zaretskii 2016-01-11 4:57 ` Masaru Nomiya 2016-01-11 5:23 ` Masaru Nomiya 2016-01-11 18:25 ` Eli Zaretskii 2016-01-12 9:21 ` 野宮 賢 / NOMIYA Masaru 2016-01-12 20:24 ` K. Handa [not found] <87d1t6l389.wl%nomiya@galaxy.dti.ne.jp> 2016-01-14 0:21 ` K. Handa 2016-01-14 1:53 ` Masaru Nomiya 2016-01-14 13:02 ` K. Handa 2016-01-15 4:54 ` Masaru Nomiya 2016-01-20 15:04 ` K. Handa 2016-01-20 23:45 ` Masaru Nomiya 2016-01-21 23:55 ` Masaru Nomiya 2016-01-22 12:48 ` K. Handa 2016-01-14 8:09 ` Masaru Nomiya
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.