bug#16126: 24.3.50; segfault on Cygwin

bug#16126: 24.3.50; segfault on Cygwin

[Katsumi Yamaoka]

Emacs -Q from the trunk head segfaults on Cygwin by `C-x 5 2'.
Here is a backtrace:

GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special)
[...]
(gdb) r -Q
Starting program: /Work/emacs/src/emacs -Q
[New Thread 5904.0x18ac]
[New Thread 5904.0x1bb8]
[New Thread 5904.0x1acc]
[New Thread 5904.0x1ce0]
[New Thread 5904.0x1b9c]
[New Thread 5904.0x1ec8]
[New Thread 5904.0x1c18]
[New Thread 5904.0x1074]
[New Thread 5904.0xd80]
[New Thread 5904.0x1a34]
[New Thread 5904.0x1ea8]
[New Thread 5904.0x1a04]
[New Thread 5904.0x164c]
[New Thread 5904.0x1594]

Program received signal SIGSEGV, Segmentation fault.
0x0053c90d in font_close_object (font_object=font_object@entry=538803829)
    at font.c:2902
2902	  FRAME_DISPLAY_INFO (font->frame)->n_fonts--;
(gdb) bt
#0  0x0053c90d in font_close_object (font_object=font_object@entry=538803829)
    at font.c:2902
#1  0x0050e71c in cleanup_vector (vector=vector@entry=0x201d7e70)
    at alloc.c:2883
#2  0x005127fc in sweep_vectors () at alloc.c:2929
#3  gc_sweep () at alloc.c:6631
#4  Fgarbage_collect () at alloc.c:5554
#5  0x00528f21 in maybe_gc () at lisp.h:4476
#6  Ffuncall (nargs=2, args=0x229ce0) at eval.c:2756
#7  0x00527a62 in internal_condition_case_n (bfun=0x528d60 <Ffuncall>, 
    nargs=nargs@entry=2, args=args@entry=0x229ce0, handlers=8480818, 
    hfun=hfun@entry=0x41ef50 <safe_eval_handler>) at eval.c:1426
#8  0x0041c2d1 in safe_call (nargs=<optimized out>, nargs@entry=2, 
    func=<optimized out>, func@entry=8500874) at xdisp.c:2562
#9  0x0041d5ff in safe_call1 (fn=8500874, arg=arg@entry=10854270)
    at xdisp.c:2578
#10 0x004d2b47 in map_keymap_canonical (map=map@entry=10854270, 
    fun=fun@entry=0x4459c0 <single_menu_item>, args=8480794, 
    data=data@entry=0x229d74) at keymap.c:668
#11 0x0044596e in single_keymap_panes (keymap=keymap@entry=10854270, 
    pane_name=<optimized out>, prefix=prefix@entry=11072538, maxdepth=8)
    at menu.c:303
#12 0x00445bf5 in single_menu_item (key=11072538, item=10888414, 
    dummy=dummy@entry=8480794, skp_v=skp_v@entry=0x229e34) at menu.c:436
#13 0x004d190a in map_keymap_item (data=0x229e34, val=<optimized out>, 
    key=<optimized out>, args=8480794, fun=0x4459c0 <single_menu_item>)
    at keymap.c:566
#14 map_keymap_internal (map=<optimized out>, 
    fun=fun@entry=0x4459c0 <single_menu_item>, args=args@entry=8480794, 
    data=0x229e34) at keymap.c:605
#15 0x004d2b5a in map_keymap_canonical (map=<optimized out>, 
    map@entry=10890462, fun=fun@entry=0x4459c0 <single_menu_item>, 
    args=8480794, data=data@entry=0x229e34) at keymap.c:670
#16 0x0044596e in single_keymap_panes (keymap=keymap@entry=10890462, 
    pane_name=<optimized out>, prefix=prefix@entry=10535514, maxdepth=9)
    at menu.c:303
#17 0x00445bf5 in single_menu_item (key=10535514, item=11230014, 
    dummy=dummy@entry=8480794, skp_v=skp_v@entry=0x229ef4) at menu.c:436
#18 0x004d190a in map_keymap_item (data=0x229ef4, val=<optimized out>, 
    key=<optimized out>, args=8480794, fun=0x4459c0 <single_menu_item>)
    at keymap.c:566
#19 map_keymap_internal (map=<optimized out>, 
    fun=fun@entry=0x4459c0 <single_menu_item>, args=args@entry=8480794, 
    data=0x229ef4) at keymap.c:605
#20 0x004d2b5a in map_keymap_canonical (map=<optimized out>, 
    map@entry=11231814, fun=fun@entry=0x4459c0 <single_menu_item>, 
    args=8480794, data=data@entry=0x229ef4) at keymap.c:670
#21 0x0044596e in single_keymap_panes (keymap=11231814, 
    pane_name=<optimized out>, prefix=<optimized out>, 
    maxdepth=maxdepth@entry=10) at menu.c:303
#22 0x00446b5c in parse_single_submenu (item_key=item_key@entry=10484410, 
    item_name=6719577, maps=<optimized out>, maps@entry=545764174)
    at menu.c:565
#23 0x00447c3a in set_frame_menubar (f=f@entry=0x20458c98, 
    first_time=first_time@entry=true, deep_p=deep_p@entry=true) at xmenu.c:878
#24 0x0044827e in initialize_frame_menubar (f=f@entry=0x20458c98)
    at xmenu.c:1118
#25 0x004a5935 in Fx_create_frame (parms=545766926) at xfns.c:3175
#26 0x00529174 in Ffuncall (nargs=2, args=0x22a274) at eval.c:2805
#27 0x00559fbb in exec_byte_code (bytestr=0, vector=0, maxdepth=16, 
    args_template=8480794, nargs=nargs@entry=0, args=0x22a278)
    at bytecode.c:919
#28 0x00528c25 in funcall_lambda (fun=6255405, nargs=nargs@entry=1, 
    arg_vector=arg_vector@entry=0x22a408) at eval.c:3039
#29 0x00528f4b in Ffuncall (nargs=2, args=0x22a404) at eval.c:2866
#30 0x00559fbb in exec_byte_code (bytestr=0, vector=0, maxdepth=20, 
    args_template=8480794, nargs=nargs@entry=0, args=0x22a400)
    at bytecode.c:919
#31 0x00528c25 in funcall_lambda (fun=6580165, nargs=nargs@entry=0, 
    arg_vector=arg_vector@entry=0x22a598) at eval.c:3039
#32 0x00528f4b in Ffuncall (nargs=1, args=0x22a594) at eval.c:2866
#33 0x00559fbb in exec_byte_code (bytestr=0, vector=0, maxdepth=8, 
    args_template=8480794, nargs=nargs@entry=0, args=0x22a590)
    at bytecode.c:919
#34 0x00528c25 in funcall_lambda (fun=6579997, nargs=nargs@entry=0, 
    arg_vector=arg_vector@entry=0x22a734) at eval.c:3039
#35 0x00528f4b in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x22a730)
    at eval.c:2866
#36 0x0052a4f7 in apply1 (fn=fn@entry=10470642, arg=arg@entry=8480794)
    at eval.c:2571
#37 0x0052541a in Fcall_interactively (function=10470642, record_flag=8480794, 
    keys=8498037) at callint.c:378
#38 0x0052914d in Ffuncall (nargs=4, args=0x22a83c) at eval.c:2812
#39 0x00559fbb in exec_byte_code (bytestr=0, vector=0, maxdepth=52, 
    args_template=args_template@entry=4100, nargs=nargs@entry=1, args=0x22a82c)
    at bytecode.c:919
#40 0x00528ca2 in funcall_lambda (fun=6451101, nargs=nargs@entry=1, 
    arg_vector=arg_vector@entry=0x22a9dc) at eval.c:2973
#41 0x00528f4b in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x22a9d8)
    at eval.c:2866
#42 0x005292c7 in call1 (fn=8514450, arg1=10470642) at eval.c:2604
#43 0x004cca17 in command_loop_1 () at keyboard.c:1552
#44 0x00527763 in internal_condition_case (
    bfun=bfun@entry=0x4cc6f0 <command_loop_1>, handlers=8523018, 
    hfun=hfun@entry=0x4c4340 <cmd_error>) at eval.c:1344
#45 0x004bffc0 in command_loop_2 (ignore=8480794) at keyboard.c:1170
#46 0x00527690 in internal_catch (tag=8512922, 
    func=func@entry=0x4bffa0 <command_loop_2>, arg=8480794) at eval.c:1108
#47 0x004c3fb1 in command_loop () at keyboard.c:1149
#48 recursive_edit_1 () at keyboard.c:777
#49 0x004c425d in Frecursive_edit () at keyboard.c:841
#50 0x005ae4d8 in main (argc=<optimized out>, argv=0x22ac0c) at emacs.c:1634
(gdb) xbacktrace
"Automatic GC" (0x7e9834)
"keymap-canonicalize" (0x229ce4)
"x-create-frame" (0x22a278)
"x-create-frame-with-faces" (0x22a408)
"make-frame" (0x22a598)
"make-frame-command" (0x22a734)
"call-interactively" (0x22a840)
"command-execute" (0x22a9dc)
(gdb) q

Thanks.

In GNU Emacs 24.3.50.1 (i686-pc-cygwin, GTK+ Version 3.8.2)
 of 2013-12-13 on localhost
Bzr revision: 115501 juri@jurta.org-20131213010304-6kewf86rikolkbqa
Windowing system distributor `The Cygwin/X Project', version 11.0.11404000
Configured using:
 `configure --verbose --with-x-toolkit=gtk3'

bug#16126: 24.3.50; segfault on Cygwin

[Dmitry Antipov]

On 12/13/2013 06:07 AM, Katsumi Yamaoka wrote:

> Program received signal SIGSEGV, Segmentation fault.
> 0x0053c90d in font_close_object (font_object=font_object@entry=538803829)
>      at font.c:2902
> 2902	  FRAME_DISPLAY_INFO (font->frame)->n_fonts--;

Do you have --enable-checking enabled?

If font->frame is not NULL, could you also please do:

(gdb) p *font->frame

and

(gdb) p *font->frame->output_data.x->display_info

Dmitry

bug#16126: 24.3.50; segfault on Cygwin

[Katsumi Yamaoka]

Dmitry Antipov wrote:
> On 12/13/2013 06:07 AM, Katsumi Yamaoka wrote:
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0053c90d in font_close_object (font_object=font_object@entry=538803829)
>>      at font.c:2902
>> 2902	  FRAME_DISPLAY_INFO (font->frame)->n_fonts--;

> Do you have --enable-checking enabled?

Ok, I used --enable-checking=yes and CFLAGS=-O0, and rebuilt
Emacs.

> If font->frame is not NULL, could you also please do:
> (gdb) p *font->frame
> and
> (gdb) p *font->frame->output_data.x->display_info

Program received signal SIGSEGV, Segmentation fault.
0x005ce4d5 in font_close_object ()
(gdb) p font->frame
No symbol "font" in current context.
(gdb) p *font->frame
No symbol "font" in current context.
(gdb) p *font->frame->output_data.x->display_info
No symbol "font" in current context.

Hm, there is no meaningful info, isn't it?
Before this I rebuilt Emacs without specifying CFLAGS, and got
``value has been optimized out'' for all those.

Thanks.

bug#16126: 24.3.50; segfault on Cygwin

[Eli Zaretskii]

> Date: Fri, 13 Dec 2013 16:44:40 +0900
> From: Katsumi Yamaoka <yamaoka@jpl.org>
> Cc: 16126@debbugs.gnu.org
> 
> Dmitry Antipov wrote:
> > On 12/13/2013 06:07 AM, Katsumi Yamaoka wrote:
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x0053c90d in font_close_object (font_object=font_object@entry=538803829)
> >>      at font.c:2902
> >> 2902	  FRAME_DISPLAY_INFO (font->frame)->n_fonts--;
> 
> > Do you have --enable-checking enabled?
> 
> Ok, I used --enable-checking=yes and CFLAGS=-O0, and rebuilt
> Emacs.
> 
> > If font->frame is not NULL, could you also please do:
> > (gdb) p *font->frame
> > and
> > (gdb) p *font->frame->output_data.x->display_info
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x005ce4d5 in font_close_object ()
> (gdb) p font->frame
> No symbol "font" in current context.
> (gdb) p *font->frame
> No symbol "font" in current context.
> (gdb) p *font->frame->output_data.x->display_info
> No symbol "font" in current context.
> 
> Hm, there is no meaningful info, isn't it?
> Before this I rebuilt Emacs without specifying CFLAGS, and got
> ``value has been optimized out'' for all those.

There was a discussion yesterday on the Cygwin list about a similar
problem (I think), and the solution was to do some cleanup with your
font configuration.  Perhaps your problem is similar?

bug#16126: 24.3.50; segfault on Cygwin

[Katsumi Yamaoka]

Eli Zaretskii wrote:
> There was a discussion yesterday on the Cygwin list about a similar
> problem (I think), and the solution was to do some cleanup with your
> font configuration.  Perhaps your problem is similar?

If you talk about the thread

Fwd: emacs-X11 memory problem after Windows update

, I don't seem to be the case.  But it is possible that Windows
Update I did the day before yesterday is the cause.

bug#16126: 24.3.50; segfault on Cygwin

[Eli Zaretskii]

> Date: Fri, 13 Dec 2013 17:36:17 +0900
> From: Katsumi Yamaoka <yamaoka@jpl.org>
> Cc: dmantipov@yandex.ru, 16126@debbugs.gnu.org
> 
> Eli Zaretskii wrote:
> > There was a discussion yesterday on the Cygwin list about a similar
> > problem (I think), and the solution was to do some cleanup with your
> > font configuration.  Perhaps your problem is similar?
> 
> If you talk about the thread
> 
> Fwd: emacs-X11 memory problem after Windows update
> 
> , I don't seem to be the case.  But it is possible that Windows
> Update I did the day before yesterday is the cause.

Did you try to run fc-cache, which helped this user of Cygwin:

  http://sourceware.org/ml/cygwin/2013-12/msg00250.html

bug#16126: 24.3.50; segfault on Cygwin

[Katsumi Yamaoka]

Eli Zaretskii wrote:
>> Date: Fri, 13 Dec 2013 17:36:17 +0900
>> From: Katsumi Yamaoka <yamaoka@jpl.org>
>> Cc: dmantipov@yandex.ru, 16126@debbugs.gnu.org

>> Eli Zaretskii wrote:
>>> There was a discussion yesterday on the Cygwin list about a similar
>>> problem (I think), and the solution was to do some cleanup with your
>>> font configuration.  Perhaps your problem is similar?

>> If you talk about the thread

>> Fwd: emacs-X11 memory problem after Windows update

>> , I don't seem to be the case.  But it is possible that Windows
>> Update I did the day before yesterday is the cause.

> Did you try to run fc-cache, which helped this user of Cygwin:

>   http://sourceware.org/ml/cygwin/2013-12/msg00250.html

I tried: fc-cache -fsv
But it made no difference.  To begin with, I can use emacs-X11
(24.3, Cygwin distributed) with no problem.  So, I still suspect
this problem is due to a recent change in the trunk.

bug#16126: 24.3.50; segfault on Cygwin

[Katsumi Yamaoka]

Katsumi Yamaoka wrote:
[...]
> So, I still suspect this problem is due to a recent change in
> the trunk.

The problem seems to have gone for today's Emacs build (maybe
r115506 dit it).  Thanks.