Emacs 22.1 reproducible crash

Emacs 22.1 reproducible crash

[Gardner Bell]

Hello,

When building emacs 22.1 with GTK+ enabled I am able to trigger the
following crash by opening any plain text file.  Operating system info
and  GCC version listed below.

If any further information is required from my debug build please let
me know and I will provide it for you.

dan@home$ uname -a
FreeBSD home.bsdca.com 7.0-CURRENT FreeBSD 7.0-CURRENT #3: Thu Jul 26
15:29:51 EDT 2007     root@home.bsdca.com:/usr/obj/usr/src/sys/HOME 
i386

dan@home$ gcc -v
Using built-in specs.
Target: i386-undermydesk-freebsd
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 4.2.0 20070514 [FreeBSD]

http://pastebin.ca/639673

Gardner

Re: Emacs 22.1 reproducible crash

[Giorgos Keramidas]

On 2007-07-30 15:43, Gardner Bell <gbell72@rogers.com> wrote:
> Hello,
>
> When building emacs 22.1 with GTK+ enabled I am able to trigger the
> following crash by opening any plain text file.  Operating system info
> and  GCC version listed below.
>
> If any further information is required from my debug build please let
> me know and I will provide it for you.
>
> dan@home$ uname -a
> FreeBSD home.bsdca.com 7.0-CURRENT FreeBSD 7.0-CURRENT #3: Thu Jul 26
> 15:29:51 EDT 2007     root@home.bsdca.com:/usr/obj/usr/src/sys/HOME
> i386
>
> dan@home$ gcc -v
> Using built-in specs.
> Target: i386-undermydesk-freebsd
> Configured with: FreeBSD/i386 system compiler
> Thread model: posix
> gcc version 4.2.0 20070514 [FreeBSD]
>
> http://pastebin.ca/639673

Please do not use pastebin URLs in emacs-devel.  Many of the subscribers
read their email offline, and they will not be able to read your pasted
text.  I apologize for not having told you this already, when we talked
about posting the crash details...

I copied the pasted text below:

------------------------------------------------------------------------
(gdb) run
Starting program: /usr/local/bin/emacs
[New LWP 100126]
[New Thread 0x83a5000 (LWP 100126)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x83a5000 (LWP 100126)]
0x081a6476 in _free_internal (ptr=0x29aa3e00) at gmalloc.c:1245
1245              next->next = prev->next;
(gdb) bt
#0  0x081a6476 in _free_internal (ptr=0x29aa3e00) at gmalloc.c:1245
#1  0x0814bc61 in emacs_blocked_free (ptr=0x29aa3e00, ptr2=0x29aa3f00)
    at alloc.c:1207
#2  0x288d098b in g_slice_get_config () from /usr/local/lib/libglib-2.0.so.0
#3  0x288d0c41 in g_slice_get_config () from /usr/local/lib/libglib-2.0.so.0
#4  0x288d0c95 in g_slice_get_config () from /usr/local/lib/libglib-2.0.so.0
#5  0x288d1689 in g_slice_free1 () from /usr/local/lib/libglib-2.0.so.0
#6  0x288a86dd in g_datalist_clear () from /usr/local/lib/libglib-2.0.so.0
#7  0x288625bf in g_object_type_init () from /usr/local/lib/libgobject-2.0.so.0
#8  0x2832a847 in gtk_object_destroy () from /usr/local/lib/libgtk-x11-2.0.so.0
#9  0x28404ec3 in gtk_widget_get_default_style ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#10 0x284193db in gtk_window_new () from /usr/local/lib/libgtk-x11-2.0.so.0
#11 0x2886040c in g_object_unref () from /usr/local/lib/libgobject-2.0.so.0
#12 0x288607e1 in g_object_run_dispose ()
   from /usr/local/lib/libgobject-2.0.so.0
#13 0x2832a605 in gtk_object_destroy () from /usr/local/lib/libgtk-x11-2.0.so.0
#14 0x2840c47b in gtk_widget_destroy () from /usr/local/lib/libgtk-x11-2.0.so.0
#15 0x28310986 in gtk_menu_attach_to_widget ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#16 0x2886ac59 in g_cclosure_marshal_VOID__VOID ()
   from /usr/local/lib/libgobject-2.0.so.0
#17 0x2885c93d in g_value_set_static_boxed ()
   from /usr/local/lib/libgobject-2.0.so.0
#18 0x2885e217 in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0
#19 0x288731f2 in g_signal_has_handler_pending ()
   from /usr/local/lib/libgobject-2.0.so.0
#20 0x28873bb8 in g_signal_emit_valist ()
   from /usr/local/lib/libgobject-2.0.so.0
#21 0x28873fab in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0
#22 0x2832a886 in gtk_object_destroy () from /usr/local/lib/libgtk-x11-2.0.so.0
#23 0x2840c21d in gtk_widget_hide () from /usr/local/lib/libgtk-x11-2.0.so.0
#24 0x288607d9 in g_object_run_dispose ()
   from /usr/local/lib/libgobject-2.0.so.0
#25 0x2832a605 in gtk_object_destroy () from /usr/local/lib/libgtk-x11-2.0.so.0
#26 0x2840c47b in gtk_widget_destroy () from /usr/local/lib/libgtk-x11-2.0.so.0
#27 0x283186fa in gtk_menu_item_new_with_label ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#28 0x2886ac59 in g_cclosure_marshal_VOID__VOID ()
   from /usr/local/lib/libgobject-2.0.so.0
#29 0x2885c93d in g_value_set_static_boxed ()
   from /usr/local/lib/libgobject-2.0.so.0
#30 0x2885e29a in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0
#31 0x288731f2 in g_signal_has_handler_pending ()
   from /usr/local/lib/libgobject-2.0.so.0
#32 0x28873bb8 in g_signal_emit_valist ()
   from /usr/local/lib/libgobject-2.0.so.0
#33 0x28873fab in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0
#34 0x2832a886 in gtk_object_destroy () from /usr/local/lib/libgtk-x11-2.0.so.0
#35 0x2840c21d in gtk_widget_hide () from /usr/local/lib/libgtk-x11-2.0.so.0
#36 0x288607d9 in g_object_run_dispose ()
   from /usr/local/lib/libgobject-2.0.so.0
#37 0x2832a605 in gtk_object_destroy () from /usr/local/lib/libgtk-x11-2.0.so.0
#38 0x2840c47b in gtk_widget_destroy () from /usr/local/lib/libgtk-x11-2.0.so.0
#39 0x080efb9b in xg_destroy_widgets (list=0x29aa2740) at gtkutil.c:2337
#40 0x080f16f1 in xg_update_submenu (submenu=0x29a70600, f=0x8710200,
    val=0x8879d80, select_cb=0x808bfa0 <menubar_selection_callback>,
    deactivate_cb=0x808b570 <popup_deactivate_callback>,
    highlight_cb=0x808cd50 <menu_highlight_callback>, cl_data=0x87c5ae0)
    at gtkutil.c:2776
#41 0x080f194b in xg_update_submenu (submenu=0x29a3ecb0, f=0x8710200, val=Variable "val" is not available.
)
    at gtkutil.c:2754
#42 0x080f194b in xg_update_submenu (submenu=0x29a27e50, f=0x8710200, val=Variable "val" is not available.
)
    at gtkutil.c:2754
#43 0x080f2040 in xg_modify_menubar_widgets (menubar=0x29a13490, f=0x8710200,
    val=0x870a1c0, deep_p=1, select_cb=0x808bfa0 <menubar_selection_callback>,
    deactivate_cb=0x808b570 <popup_deactivate_callback>,
    highlight_cb=0x808cd50 <menu_highlight_callback>) at gtkutil.c:2861
#44 0x0808ca5b in set_frame_menubar (f=0x8710200, first_time=0, deep_p=1) at xmenu.c:2393
#45 0x0808ce46 in x_activate_menubar (f=0x8710200) at xmenu.c:1472
#46 0x08102fcd in read_char (commandflag=1, nmaps=2, maps=0xbfbfe440,
    prev_event=674383872, used_mouse_menu=0xbfbfe4d8, end_time=0x0)
    at keyboard.c:4137
#47 0x08104488 in read_key_sequence (keybuf=0xbfbfe594, bufsize=30,
    prompt=674383872, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:9135
#48 0x08106025 in command_loop_1 () at keyboard.c:1618
#49 0x0815e73b in internal_condition_case (bfun=0x8105e90 <command_loop_1>,
    handlers=674436720, hfun=0x8100600 <cmd_error>) at eval.c:1481
#50 0x080ffa03 in command_loop_2 () at keyboard.c:1329
#51 0x0815e7f5 in internal_catch (tag=674432984,
    func=0x80ff9e0 <command_loop_2>, arg=674383872) at eval.c:1222
#52 0x0810043c in command_loop () at keyboard.c:1308
#53 0x081007da in recursive_edit_1 () at keyboard.c:1006
#54 0x081008c6 in Frecursive_edit () at keyboard.c:1067
#55 0x080f67e0 in main (argc=1, argv=0xbfbfe8a4) at emacs.c:1762
(gdb) list *0x080f67e0
0x80f67e0 is in main (emacs.c:1765).
1760
1761      /* Enter editor command loop.  This never returns.  */
1762      Frecursive_edit ();
1763      /* NOTREACHED */
1764      return 0;
1765    }
1766    ^L
1767    /* Sort the args so we can find the most important ones
1768       at the beginning of argv.  */
1769
(gdb) return
Make _free_internal return now? (y or n) y
#0  emacs_blocked_free (
    ptr=0x29aa3e00, ptr2=0x29aa3f00) at alloc.c:1212
1212      if (! NILP (Vmemory_full)
(gdb) info frame
Stack level 0, frame at 0xbfbfce20:
 eip = 0x814bc61 in emacs_blocked_free (alloc.c:1212); saved eip 0x288d098b
 called by frame at 0xbfbfce50
 source language c.
 Arglist at 0xbfbfce18, args: ptr=0x29aa3e00, ptr2=0x29aa3f00
 Locals at 0xbfbfce18, Previous frame's sp is 0xbfbfce20
 Saved registers:
  ebx at 0xbfbfce10, ebp at 0xbfbfce18, esi at 0xbfbfce14, eip at 0xbfbfce1c
(gdb)
------------------------------------------------------------------------

Re: Emacs 22.1 reproducible crash

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 30 Jul 2007 15:43:26 -0400 (EDT), Gardner Bell <gbell72@rogers.com> said:

> Hello, When building emacs 22.1 with GTK+ enabled I am able to
> trigger the following crash by opening any plain text file.
> Operating system info and GCC version listed below.

Could you replace src/gmalloc.c in the source tree with the latest one
in the trunk (*) and try to reproduce the crash?

  (*) http://cvs.savannah.gnu.org/viewvc/*checkout*/emacs/src/gmalloc.c?revision=1.24&root=emacs

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Emacs 22.1 reproducible crash

[Gardner Bell]

--- YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:

> >>>>> On Mon, 30 Jul 2007 15:43:26 -0400 (EDT), Gardner Bell
> <gbell72@rogers.com> said:
> 
> > Hello, When building emacs 22.1 with GTK+ enabled I am able to
> > trigger the following crash by opening any plain text file.
> > Operating system info and GCC version listed below.
> 
> Could you replace src/gmalloc.c in the source tree with the latest
> one
> in the trunk (*) and try to reproduce the crash?
> 
>   (*)
>
http://cvs.savannah.gnu.org/viewvc/*checkout*/emacs/src/gmalloc.c?revision=1.24&root=emacs
> 
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
> 

After running make clean and make distclean the gmalloc.c from trunk
causes this segfault during make.

LC_ALL=C ./temacs -batch -l loadup dump
Segmentation fault
*** Error code 139

Stop in /home/dan/emacs-22.1/src.
*** Error code 1

Stop in /home/dan/emacs-22.1.

Re: Emacs 22.1 reproducible crash

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 31 Jul 2007 07:10:20 -0400 (EDT), Gardner Bell <gbell72@rogers.com> said:

> After running make clean and make distclean the gmalloc.c from trunk
> causes this segfault during make.

Could you try with the latest src/emacs.c and src/gmalloc.c in the
EMACS_22_BASE branch?

  http://cvs.savannah.gnu.org/viewvc/*checkout*/emacs/src/emacs.c?revision=1.401.2.2&root=emacs&pathrev=EMACS_22_BASE
  http://cvs.savannah.gnu.org/viewvc/*checkout*/emacs/src/gmalloc.c?revision=1.21.2.4&root=emacs&pathrev=EMACS_22_BASE

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Emacs 22.1 reproducible crash

[Gardner Bell]

--- YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:

> >>>>> On Tue, 31 Jul 2007 07:10:20 -0400 (EDT), Gardner Bell
> <gbell72@rogers.com> said:
> 
> > After running make clean and make distclean the gmalloc.c from
> trunk
> > causes this segfault during make.
> 
> Could you try with the latest src/emacs.c and src/gmalloc.c in the
> EMACS_22_BASE branch?
> 
>  
>
http://cvs.savannah.gnu.org/viewvc/*checkout*/emacs/src/emacs.c?revision=1.401.2.2&root=emacs&pathrev=EMACS_22_BASE
>  
>
http://cvs.savannah.gnu.org/viewvc/*checkout*/emacs/src/gmalloc.c?revision=1.21.2.4&root=emacs&pathrev=EMACS_22_BASE
> 
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
> 

Same thing, slightly different backtrace this time.  I have also
noticed that this is triggered much easier when using the mouse to
open, and close files.

(gdb) run
Starting program: /usr/local/bin/emacs 
[New LWP 100092]
[New Thread 0x836f000 (LWP 100092)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x836f000 (LWP 100092)]
0x081a0e80 in _free_internal_nolock (ptr=0x29a98000) at gmalloc.c:1327
1327              next->next = prev->next;

(gdb) where
#0  0x081a0e80 in _free_internal_nolock (ptr=0x29a98000) at
gmalloc.c:1327
#1  0x081a151b in _free_internal (ptr=0x29a98000) at gmalloc.c:1363
#2  0x08147fa1 in emacs_blocked_free (ptr=0x29a98000, ptr2=0x29a98100)
    at alloc.c:1207
#3  0x288cb98b in g_slice_get_config () from
/usr/local/lib/libglib-2.0.so.0
#4  0x288cbc41 in g_slice_get_config () from
/usr/local/lib/libglib-2.0.so.0
#5  0x288cbc95 in g_slice_get_config () from
/usr/local/lib/libglib-2.0.so.0
#6  0x288cc689 in g_slice_free1 () from /usr/local/lib/libglib-2.0.so.0
#7  0x288aa06d in g_hash_table_lookup_extended ()
   from /usr/local/lib/libglib-2.0.so.0
#8  0x288aa4f4 in g_hash_table_remove_all ()
   from /usr/local/lib/libglib-2.0.so.0
#9  0x288aa72d in g_hash_table_destroy () from
/usr/local/lib/libglib-2.0.so.0
#10 0x2841ddc0 in gtk_drag_finish () from
/usr/local/lib/libgtk-x11-2.0.so.0
#11 0x2885b40c in g_object_unref () from
/usr/local/lib/libgobject-2.0.so.0
#12 0x282c2626 in gtk_file_info_render_icon ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#13 0x2885b40c in g_object_unref () from
/usr/local/lib/libgobject-2.0.so.0
#14 0x283cf249 in gtk_tree_model_filter_convert_child_iter_to_iter ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#15 0x283cf3ce in gtk_tree_model_filter_convert_child_iter_to_iter ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#16 0x2885b40c in g_object_unref () from
/usr/local/lib/libgobject-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#17 0x283e408b in gtk_tree_view_set_model ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#18 0x282add17 in gtk_file_chooser_button_new ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#19 0x2841e9dc in gtk_file_system_unix_new ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#20 0x2841eb89 in gtk_file_system_unix_new ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#21 0x288b5040 in g_source_is_destroyed () from
/usr/local/lib/libglib-2.0.so.0
#22 0x288b6cd5 in g_main_context_dispatch ()
   from /usr/local/lib/libglib-2.0.so.0
#23 0x288b9828 in g_main_context_check () from
/usr/local/lib/libglib-2.0.so.0
#24 0x288b9c15 in g_main_context_iteration ()
   from /usr/local/lib/libglib-2.0.so.0
#25 0x28303d1d in gtk_main_iteration () from
/usr/local/lib/libgtk-x11-2.0.so.0
#26 0x080f0623 in xg_get_file_name (f=0x870e200, 
    prompt=0x82bb28c "Find file: ", 
    default_filename=0x8874878 "/home/dan/emacs-22.1/", mustmatch_p=1, 
    only_dir_p=0) at gtkutil.c:1571
#27 0x080d0ec7 in Fx_file_dialog (prompt=136569160, dir=140336259, 
    default_filename=140294931, mustmatch=137492529,
only_dir_p=137492481)
    at xfns.c:5591
#28 0x0812887e in Fread_file_name (prompt=136569163, dir=140336259, 
---Type <return> to continue, or q <return> to quit---
    default_filename=140294931, mustmatch=137492529, initial=137492481,

    predicate=137492481) at fileio.c:6407
#29 0x0815bafc in Ffuncall (nargs=5, args=0xbfbfe140) at eval.c:3016
#30 0x08185a0c in Fbyte_code (bytestr=136171491, vector=136171508,
maxdepth=Variable "maxdepth" is not available.
)
    at bytecode.c:679
#31 0x0815b526 in funcall_lambda (fun=136171452, nargs=2, 
    arg_vector=0xbfbfe284) at eval.c:3184
#32 0x0815b930 in Ffuncall (nargs=3, args=0xbfbfe280) at eval.c:3054
#33 0x08185a0c in Fbyte_code (bytestr=136569107, vector=136569124,
maxdepth=Variable "maxdepth" is not available.
)
    at bytecode.c:679
#34 0x0815b526 in funcall_lambda (fun=136569076, nargs=0, 
    arg_vector=0xbfbfe3b4) at eval.c:3184
#35 0x0815b930 in Ffuncall (nargs=1, args=0xbfbfe3b0) at eval.c:3054
#36 0x0815d2c9 in apply1 (fn=140259473, arg=137492481) at eval.c:2738
#37 0x08158ea0 in Fcall_interactively (function=140259473, 
    record_flag=137492481, keys=137492481) at callint.c:406
#38 0x080f8354 in Fcommand_execute (cmd=140259473,
record_flag=137492481, 
    keys=137492481, special=137492481) at keyboard.c:10036
#39 0x08103869 in command_loop_1 () at keyboard.c:1873
#40 0x0815a54b in internal_condition_case (bfun=0x81034f0
<command_loop_1>,  handlers=137552497, hfun=0x80fde80 <cmd_error>) at
eval.c:1481
#41 0x080fd2d3 in command_loop_2 () at keyboard.c:1329
#42 0x0815a605 in internal_catch (tag=137541593, 
---Type <return> to continue, or q <return> to quit---
    func=0x80fd2b0 <command_loop_2>, arg=137492481) at eval.c:1222
#43 0x080fdcbc in command_loop () at keyboard.c:1308
#44 0x080fe05a in recursive_edit_1 () at keyboard.c:1006
#45 0x080fe146 in Frecursive_edit () at keyboard.c:1067
#46 0x080f4375 in main (argc=1, argv=0xbfbfe87c) at emacs.c:1769
(gdb) return
Make _free_internal_nolock return now? (y or n) y
#0  _free_internal (
    ptr=0x29a98000) at gmalloc.c:1364
1364      UNLOCK ();
(gdb)

Re: Emacs 22.1 reproducible crash

[Jan Djärv]

Gardner Bell skrev:
> --- YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:
> 
>>>>>>> On Tue, 31 Jul 2007 07:10:20 -0400 (EDT), Gardner Bell
>> <gbell72@rogers.com> said:
>>
>>> After running make clean and make distclean the gmalloc.c from
>> trunk
>>> causes this segfault during make.
>> Could you try with the latest src/emacs.c and src/gmalloc.c in the
>> EMACS_22_BASE branch?
>>
>>  
>>
> http://cvs.savannah.gnu.org/viewvc/*checkout*/emacs/src/emacs.c?revision=1.401.2.2&root=emacs&pathrev=EMACS_22_BASE
>>  
>>
> http://cvs.savannah.gnu.org/viewvc/*checkout*/emacs/src/gmalloc.c?revision=1.21.2.4&root=emacs&pathrev=EMACS_22_BASE
>> 				     YAMAMOTO Mitsuharu
>> 				mituharu@math.s.chiba-u.ac.jp
>>
> 
> Same thing, slightly different backtrace this time.  I have also
> noticed that this is triggered much easier when using the mouse to
> open, and close files.
> 

I think this might be due to the fact that Glib uses posix_memalign, but there
is no posix_memalign in gmalloc.c.

	Jan D.

Re: Emacs 22.1 reproducible crash

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 07 Aug 2007 14:03:51 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

>> Same thing, slightly different backtrace this time.  I have also
>> noticed that this is triggered much easier when using the mouse to
>> open, and close files.

> I think this might be due to the fact that Glib uses posix_memalign,
> but there is no posix_memalign in gmalloc.c.

Then adding its implementation to gmalloc.c simply work?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/gmalloc.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/gmalloc.c,v
retrieving revision 1.25
diff -c -p -r1.25 gmalloc.c
*** src/gmalloc.c	7 Aug 2007 08:55:43 -0000	1.25
--- src/gmalloc.c	8 Aug 2007 02:31:42 -0000
*************** memalign (alignment, size)
*** 1857,1862 ****
--- 1857,1891 ----
    return result;
  }
  
+ #ifndef ENOMEM
+ #define ENOMEM 12
+ #endif
+ 
+ #ifndef EINVAL
+ #define EINVAL 22
+ #endif
+ 
+ int
+ posix_memalign (memptr, alignment, size)
+      __ptr_t *memptr;
+      __malloc_size_t alignment;
+      __malloc_size_t size;
+ {
+   __ptr_t mem;
+ 
+   if (alignment % sizeof (__ptr_t) != 0
+       || (alignment & (alignment - 1)) != 0)
+     return EINVAL;
+ 
+   mem = memalign (alignment, size);
+   if (mem == NULL)
+     return ENOMEM;
+ 
+   *memptr = mem;
+ 
+   return 0;
+ }
+ 
  #endif /* Not DJGPP v1 */
  /* Allocate memory on a page boundary.
     Copyright (C) 1991, 92, 93, 94, 96 Free Software Foundation, Inc.

Re: Emacs 22.1 reproducible crash

[Stefan Monnier]

> + int
> + posix_memalign (memptr, alignment, size)
> +      __ptr_t *memptr;
> +      __malloc_size_t alignment;
> +      __malloc_size_t size;
> + {
> +   __ptr_t mem;
> + 
> +   if (alignment % sizeof (__ptr_t) != 0
> +       || (alignment & (alignment - 1)) != 0)
> +     return EINVAL;
> + 
> +   mem = memalign (alignment, size);
> +   if (mem == NULL)
> +     return ENOMEM;
> + 
> +   *memptr = mem;
> + 
> +   return 0;
> + }

Can the result be freed by passing it to `free'?
That's a very important part of the spec.


        Stefan

Re: Emacs 22.1 reproducible crash

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 07 Aug 2007 23:31:12 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> + int
>> + posix_memalign (memptr, alignment, size)
>> +      __ptr_t *memptr;
>> +      __malloc_size_t alignment;
>> +      __malloc_size_t size;
>> + {
>> +   __ptr_t mem;
>> + 
>> +   if (alignment % sizeof (__ptr_t) != 0
>> +       || (alignment & (alignment - 1)) != 0)
>> +     return EINVAL;
>> + 
>> +   mem = memalign (alignment, size);
>> +   if (mem == NULL)
>> +     return ENOMEM;
>> + 
>> +   *memptr = mem;
>> + 
>> +   return 0;
>> + }

> Can the result be freed by passing it to `free'?
> That's a very important part of the spec.

Yes.  The function `memalign', which is also implemented in gmalloc.c,
records the original return value of `malloc' in the linear list
starting from `_aligned_blocks', and `free' looks through it first.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Emacs 22.1 reproducible crash

[Stefan Monnier]

>> Can the result be freed by passing it to `free'?
>> That's a very important part of the spec.

> Yes.  The function `memalign', which is also implemented in gmalloc.c,
> records the original return value of `malloc' in the linear list
> starting from `_aligned_blocks', and `free' looks through it first.

Good.  (I guess the overhead of searching through a linear list shouldn't
be too much problem, although we may end up having many aligned blocks).

Then after installing the above change, we should fix the logic in alloc.c:

   /* Use posix_memalloc if the system has it and we're using the system's
      malloc (because our gmalloc.c routines don't have posix_memalign although
      its memalloc could be used).  */
   #if defined (HAVE_POSIX_MEMALIGN) && defined (SYSTEM_MALLOC)
   #define USE_POSIX_MEMALIGN 1
   #endif


-- Stefan

Re: Emacs 22.1 reproducible crash

[Giorgos Keramidas]

On 2007-08-08 11:32, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:
> >>>>> On Tue, 07 Aug 2007 14:03:51 +0200, Jan Dj?rv <jan.h.d@swipnet.se> said:
> 
> >> Same thing, slightly different backtrace this time.  I have also
> >> noticed that this is triggered much easier when using the mouse to
> >> open, and close files.
> 
> > I think this might be due to the fact that Glib uses posix_memalign,
> > but there is no posix_memalign in gmalloc.c.
> 
> Then adding its implementation to gmalloc.c simply work?

This may actually work well.  I recall problems with glib and
Emacs since we switched to FreeBSD in a system malloc() which
*does* include posix_memalign().

I haven't checked but it's possible that Emacs, when linked with
GTK+ links with malloc() from gmalloc.c but calls the system
version of posix_memalign().  This could definitely lead to
trouble similar to what we are seeing.

> Index: src/gmalloc.c
> ===================================================================
> RCS file: /cvsroot/emacs/emacs/src/gmalloc.c,v
> retrieving revision 1.25
> diff -c -p -r1.25 gmalloc.c
> *** src/gmalloc.c	7 Aug 2007 08:55:43 -0000	1.25
> --- src/gmalloc.c	8 Aug 2007 02:31:42 -0000
> *************** memalign (alignment, size)
> *** 1857,1862 ****
> --- 1857,1891 ----
>     return result;
>   }
>   
> + #ifndef ENOMEM
> + #define ENOMEM 12
> + #endif
> + 
> + #ifndef EINVAL
> + #define EINVAL 22
> + #endif
> + 
> + int
> + posix_memalign (memptr, alignment, size)
> +      __ptr_t *memptr;
> +      __malloc_size_t alignment;
> +      __malloc_size_t size;

Excellent, thanks :-)

I will try this with a snapshot of HEAD from CVS in a few minutes :-)

Re: Emacs 22.1 reproducible crash

[Giorgos Keramidas]

On 2007-08-08 13:00, Giorgos Keramidas <keramida@freebsd.org> wrote:
>On 2007-08-08 11:32, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:
>>>>>>> On Tue, 07 Aug 2007 14:03:51 +0200, Jan Dj?rv <jan.h.d@swipnet.se> said:
>>>> Same thing, slightly different backtrace this time.  I have also
>>>> noticed that this is triggered much easier when using the mouse to
>>>> open, and close files.
>>>
>>> I think this might be due to the fact that Glib uses posix_memalign,
>>> but there is no posix_memalign in gmalloc.c.
>>
>> Then adding its implementation to gmalloc.c simply work?
>>
>> Index: src/gmalloc.c
>> ===================================================================
>> RCS file: /cvsroot/emacs/emacs/src/gmalloc.c,v
>> retrieving revision 1.25
>> diff -c -p -r1.25 gmalloc.c
>> *** src/gmalloc.c	7 Aug 2007 08:55:43 -0000	1.25
>> --- src/gmalloc.c	8 Aug 2007 02:31:42 -0000
>> *************** memalign (alignment, size)
>> *** 1857,1862 ****
>> --- 1857,1891 ----
>>     return result;
>>   }
>>
>> + #ifndef ENOMEM
>> + #define ENOMEM 12
>> + #endif
>> +
>> + #ifndef EINVAL
>> + #define EINVAL 22
>> + #endif
>> +
>> + int
>> + posix_memalign (memptr, alignment, size)
>> +      __ptr_t *memptr;
>> +      __malloc_size_t alignment;
>> +      __malloc_size_t size;
>
> Excellent, thanks :-)
>
> I will try this with a snapshot of HEAD from CVS in a few minutes :-)

Nice.  I just finished rebuilding Emacs --with-gtk from a snapshot of
the CVS repository at:

% changeset:   82488:9563c0c734fe
% tag:         tip
% user:        gm
% date:        Wed Aug 08 08:14:03 2007 +0000
% files:       lisp/emacs-lisp/eldoc.el
% description:
% (eldoc-get-fnsym-args-string): Make second argument optional, for
% backwards compatibility, and only highlight args when present.
% Fix symbol name typo (doc/args).

A clean bootstrap now works as expected (i.e. no temacs crash while
building), and I haven't been able to crash Emacs in the first few
minutes by browsing news groups with Gnus (this used to trigger a
segfault pretty fast before).

I think we may have a fix, but let's wait until Jan completes his own
testing too :-)

Thank you for the patch,
George

Re: Emacs 22.1 reproducible crash

[Jan Djärv]

Giorgos Keramidas skrev:

> I think we may have a fix, but let's wait until Jan completes his own
> testing too :-)
> 

It works fine on FreeBSD 6.2 as well.

	Jan D.

Re: Emacs 22.1 reproducible crash

[Giorgos Keramidas]

On 2007-08-08 14:38, Jan Dj?rv <jan.h.d@swipnet.se> wrote:
>Giorgos Keramidas skrev:
>> I think we may have a fix, but let's wait until Jan completes his own
>> testing too :-)
> 
> It works fine on FreeBSD 6.2 as well.

Fantastic, thanks! :-)

Once this hits the CVS tree, I can resync and update the
editors/emacs-devel port.  In the meantime, I am going to test
building the editors/emacs port with a local FreeBSD patch,
because that port/package is based on the latest *released*
version of Emacs, which is 22.1 and doesn't include the fix.

- Giorgos

Re: Emacs 22.1 reproducible crash

[Gardner Bell]

--- Giorgos Keramidas <keramida@FreeBSD.org> wrote:

> On 2007-08-08 13:00, Giorgos Keramidas <keramida@freebsd.org> wrote:
> >On 2007-08-08 11:32, YAMAMOTO Mitsuharu
> <mituharu@math.s.chiba-u.ac.jp> wrote:
> >>>>>>> On Tue, 07 Aug 2007 14:03:51 +0200, Jan Dj?rv
> <jan.h.d@swipnet.se> said:
> >>>> Same thing, slightly different backtrace this time.  I have also
> >>>> noticed that this is triggered much easier when using the mouse
> to
> >>>> open, and close files.
> >>>
> >>> I think this might be due to the fact that Glib uses
> posix_memalign,
> >>> but there is no posix_memalign in gmalloc.c.
> >>
> >> Then adding its implementation to gmalloc.c simply work?
> >>
> >> Index: src/gmalloc.c
> >>
> ===================================================================
> >> RCS file: /cvsroot/emacs/emacs/src/gmalloc.c,v
> >> retrieving revision 1.25
> >> diff -c -p -r1.25 gmalloc.c
> >> *** src/gmalloc.c	7 Aug 2007 08:55:43 -0000	1.25
> >> --- src/gmalloc.c	8 Aug 2007 02:31:42 -0000
> >> *************** memalign (alignment, size)
> >> *** 1857,1862 ****
> >> --- 1857,1891 ----
> >>     return result;
> >>   }
> >>
> >> + #ifndef ENOMEM
> >> + #define ENOMEM 12
> >> + #endif
> >> +
> >> + #ifndef EINVAL
> >> + #define EINVAL 22
> >> + #endif
> >> +
> >> + int
> >> + posix_memalign (memptr, alignment, size)
> >> +      __ptr_t *memptr;
> >> +      __malloc_size_t alignment;
> >> +      __malloc_size_t size;
> >
> > Excellent, thanks :-)
> >
> > I will try this with a snapshot of HEAD from CVS in a few minutes
> :-)
> 
> Nice.  I just finished rebuilding Emacs --with-gtk from a snapshot of
> the CVS repository at:
> 
> % changeset:   82488:9563c0c734fe
> % tag:         tip
> % user:        gm
> % date:        Wed Aug 08 08:14:03 2007 +0000
> % files:       lisp/emacs-lisp/eldoc.el
> % description:
> % (eldoc-get-fnsym-args-string): Make second argument optional, for
> % backwards compatibility, and only highlight args when present.
> % Fix symbol name typo (doc/args).
> 
> A clean bootstrap now works as expected (i.e. no temacs crash while
> building), and I haven't been able to crash Emacs in the first few
> minutes by browsing news groups with Gnus (this used to trigger a
> segfault pretty fast before).
> 
> I think we may have a fix, but let's wait until Jan completes his own
> testing too :-)
> 
> Thank you for the patch,
> George
> 
> 

Emacs is now working quite well on this side as well with your latest
patch to gmalloc.c.  Thanks to everyone that helped work on this patch.
It has been greatly appreciated.

Re: Emacs 22.1 reproducible crash

[Giorgos Keramidas]

On 2007-07-31 10:34, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:
> >>>>> On Mon, 30 Jul 2007 15:43:26 -0400 (EDT), Gardner Bell <gbell72@rogers.com> said:
>
> > Hello, When building emacs 22.1 with GTK+ enabled I am able to
> > trigger the following crash by opening any plain text file.
> > Operating system info and GCC version listed below.
>
> Could you replace src/gmalloc.c in the source tree with the latest one
> in the trunk (*) and try to reproduce the crash?

I'm building a GTK+ enabled snapshot of trunk, based on a snapshot of
CVS after the latest commits by Miles to fix the recent cl-loaddefs.el
breakage.  The changesets I have pulled from CVS into my workspace are:

REV   | NODE         | AGE          | AUTHOR       | DESCRIPTION
------+--------------+--------------+--------------+------------------------------------------------
82385 | 9e97166af0b4 | 4 minutes    | keramida     | test patch for vc-hg-dir-state function
82384 | 9fb388d758a8 | 4 minutes    | keramida     | Bump the local pure storage size, to avoid ovef
82383 | a220c2676591 | 4 minutes    | keramida     | Use "flushw" instead of "ta 3" (trap 3) on spar
82382 | a08dbcc12e63 | 4 minutes    | keramida     | Use --no-split when formatting info docs
82381 | 5b1aa3b0ad08 | 7 hours      | miles        | Merge from emacs--rel--22
82380 | 136310da2872 | 12 hours     | miles        | Restore lisp/emacs-lisp/cl-loaddefs.el
82379 | 235350d447a9 | 13 hours     | yamaoka      | (BASE_PURESIZE): Increase to 1130000.
82378 | bfacb411b93e | 16 hours     | rms          | (emacs-lisp-mode-syntax-table): Treat non-break
82377 | d66ac66ebfd6 | 16 hours     | rms          | *** empty log message ***
82376 | aba6ead34f35 | 16 hours     | rms          | (readevalloop, read1): Treat NBSP as whitespace
82375 | aca871209ae5 | 18 hours     | monnier      | (vc-dired-hook): Use inhibit-read-only.
82374 | 1b12009f354b | 18 hours     | monnier      | (compilation-forget-errors): Reset compilation-
82373 | 1466cb0c299c | 19 hours     | bob          | *** empty log message ***

I will try to test this version with GTK+ widgets, since I haven't been
building --with-gtk for several weeks, and I don't know if it works ok
now.

- Giorgos

Re: Emacs 22.1 reproducible crash

[Giorgos Keramidas]

On 2007-07-31 15:13, Giorgos Keramidas <keramida@freebsd.org> wrote:
> On 2007-07-31 10:34, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:
> > >>>>> On Mon, 30 Jul 2007 15:43:26 -0400 (EDT), Gardner Bell <gbell72@rogers.com> said:
> >
> > > Hello, When building emacs 22.1 with GTK+ enabled I am able to
> > > trigger the following crash by opening any plain text file.
> > > Operating system info and GCC version listed below.
> >
> > Could you replace src/gmalloc.c in the source tree with the latest one
> > in the trunk (*) and try to reproduce the crash?
>
> I'm building a GTK+ enabled snapshot of trunk, based on a snapshot of
> CVS after the latest commits by Miles to fix the recent cl-loaddefs.el
> breakage.  The changesets I have pulled from CVS into my workspace are:
>
> REV   | NODE         | AGE          | AUTHOR       | DESCRIPTION
> ------+--------------+--------------+--------------+------------------------------------------------
> 82385 | 9e97166af0b4 | 4 minutes    | keramida     | test patch for vc-hg-dir-state function
> 82384 | 9fb388d758a8 | 4 minutes    | keramida     | Bump the local pure storage size, to avoid ovef
> 82383 | a220c2676591 | 4 minutes    | keramida     | Use "flushw" instead of "ta 3" (trap 3) on spar
> 82382 | a08dbcc12e63 | 4 minutes    | keramida     | Use --no-split when formatting info docs
> 82381 | 5b1aa3b0ad08 | 7 hours      | miles        | Merge from emacs--rel--22
> 82380 | 136310da2872 | 12 hours     | miles        | Restore lisp/emacs-lisp/cl-loaddefs.el
> 82379 | 235350d447a9 | 13 hours     | yamaoka      | (BASE_PURESIZE): Increase to 1130000.
> 82378 | bfacb411b93e | 16 hours     | rms          | (emacs-lisp-mode-syntax-table): Treat non-break
> 82377 | d66ac66ebfd6 | 16 hours     | rms          | *** empty log message ***
> 82376 | aba6ead34f35 | 16 hours     | rms          | (readevalloop, read1): Treat NBSP as whitespace
> 82375 | aca871209ae5 | 18 hours     | monnier      | (vc-dired-hook): Use inhibit-read-only.
> 82374 | 1b12009f354b | 18 hours     | monnier      | (compilation-forget-errors): Reset compilation-
> 82373 | 1466cb0c299c | 19 hours     | bob          | *** empty log message ***
>
> I will try to test this version with GTK+ widgets, since I haven't been
> building --with-gtk for several weeks, and I don't know if it works ok
> now.

temacs dumps core with SIGSEGV when GTK+ is enabled on the trunk.

Building with the Lucid widgets, with the command:

    ( ./configure --prefix=/opt/emacs \
      --with-x --with-x-toolkit=lucid \
      --with-xpm --with-jpeg --with-tiff --with-gif --with-png && \
      printf '\f\n' && \
      make bootstrap && \
      printf '\f\n' ) 2>&1 | tslog | tee ../emacs.log

doesn't have the same problem on the trunk today.

I'll see if I can catch 'temacs' mid-crash by running it under GDB.