Re: EFS 1.9 bug: core dump in find_file_name_handler?

sandy@ibm550.sissa.it
Fri, 1 Jul 1994 20:17:13 +0200
Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Michael Sperber [Mr. Preprocessor]: "1.9: Shouldn't + also make the directory show up?"
Previous message: jeff: "efs kills Jeff's brain (modtime bug *not* fixed)"
>>>>> On Fri, 1 Jul 94 12:25:02 BST,
      Denis Howe <dbh@doc.ic.ac.uk> said:

 > I keep getting core dumps, probably during autosave.  I suspect efs
 > because it happens in find_file_name_handler.  It could be something
 > to do with the fact that I call a function to check for mail in my
 > auto-save-hook and display-time-hook.

Any time emacs dumps core, the bug is always in emacs.  It should be
impossible to trigger a core dump with any lisp code.  In this case,
we suspect that we know the nature of the bug(s).  There seem to be
some calls to find-file-name-handler in fileio.c that don't protect
lisp variables against GC.  This can cause core dumps, or just simply
strange behaviour, because the values of some lisp variables get
changed.  Any package using the file-name-handler-alist will
potentially trigger these problems---efs more than most though, simply
because it uses the file-name-handler-alist a lot.

I am CC'ing my reply to efs-testers, as there has been some discussion
of this problem there lately.  I hope that you don't mind me passing
around your backtrace.  Probably, this should also find its way to
gnu-emacs-bug, but I'll let you do that.

Thanks for the bug report, Sandy

 > [This backtrace is for]
 > GNU Emacs 19.25.2


 > The adb stack backtrace says:

 >   adb /usr/local/bin/emacs-19.25

 >   core file = core -- program ``emacs-19.25''
 >   SIGSEGV 11: segmentation violation
 >   $c
 >   _kill() + 8
 >   _fatal_error_signal(0xb,0x3,0xf7ffcca8) + a8
 >   __sigtramp() + 94
 >   _re_search_2(0x189070,0x0,0x0,0x3d1cac,0x3ceda4,0x0) + 2d8
 >   _re_search(0x189070,0x3d1cac,0x3ceda4,0x0,0x3ceda4,0x0) + 4c
 >   _fast_string_match(0x32194b0,0x33d1ca4,0xfffc00,0x8,0x10,0x0) + 80
 >   _Ffind_file_name_handler(0x33d1ca4,0x11be144,0x11b2c2c,0x11b2c04,0x10,0x0) + 100
 >   _Fexpand_file_name(0x33d1ca4,0x11b2c04,0x75c04,0xa,0x18,0xd9000) + 54
 >   _Ffuncall(0x3,0xf7ffd8b8,0x11b2c04,0xffffff,0xcc,0x0) + 524
 >   _Fapply(0x2,0xf7ffda64,0xb1708,0x9,0x7ffffc00,0x0) + 438
 >   _Ffuncall(0x3,0xf7ffda60,0xcfc00,0x0,0x14,0x0) + 328
 >   _Fbyte_code(0x32fa518,0x2df508,0x5,0xffffff,0xfffc00,0x0) + 7ec
 >   _funcall_lambda(0x62bc6a0,0x3,0xf7ffdcd4,0x8,0x3ceda4,0x0) + 3c8
 >   _Ffuncall(0x4,0xf7ffdcd0,0xfffc00,0x8,0x10,0x0) + 694
 >   _call3(0x12f9490,0x11be144,0x33d1ca4,0x11b2c04,0x10,0x0) + 6c
 >   _Fexpand_file_name(0x33d1ca4,0x11b2c04,0x33d1ca4,0x11b2c04,0x3,0xd9000) + 8c
 >   _Ffile_executable_p(0x33d1ca4,0x187400,0x11b2c04,0x33d545c,0xf82ec66c,0x10000) + 50
 >   _Ffile_accessible_directory_p(0x33d1ca4,0x78dfc,0xffffff,0x7,0x18,0x0) + 80
 >   _Ffuncall(0x2,0xf7ffe0d4,0x33d1ca4,0xffffff,0xfffc00,0xf7ffe9ba) + 4f4
 >   _Fapply(0x2,0xf7ffe0d4,0xb1708,0x6,0x7ffffc00,0x0) + 108
 >   _Ffuncall(0x3,0xf7ffe0d0,0xcfc00,0x0,0x14,0x0) + 328
 >   _Fbyte_code(0x32fa518,0x2df508,0x5,0xffffff,0xfffc00,0x0) + 7ec
 >   _funcall_lambda(0x62bc6a0,0x2,0xf7ffe344,0x5,0x10,0x0) + 3c8
 >   _Ffuncall(0x3,0xf7ffe340,0xfffc00,0x11b2c04,0x3,0xd9000) + 694
 >   _call2(0x12f9490,0x11be2c0,0x33d1ca4,0x33d545c,0xf82ec66c,0x10000) + 60
 >   _Ffile_accessible_directory_p(0x33d1ca4,0x11b2c04,0x83,0x80,0x3,0x0) + 48
 >   _Fcall_process(0xa,0xf7ffeaec,0x33d1c3c,0x11b2c04,0x11b2ccc,0xf7ffe9ba) + 2a8
 >   _Fcall_process_region(0xc,0xf7ffeae4,0xd994c,0x4,0x1,0x1b0014) + dc
 >   _Ffuncall(0xd,0xf7ffeae0,0x326b428,0x1,0xa4,0x0) + 328
 >   _Fapply(0x2,0xf7ffecb4,0xb1708,0x3,0x89004,0x0) + 438
 >   _Ffuncall(0x3,0xf7ffecb0,0xcfc00,0x0,0x2c,0xf7ffed24) + 328
 >   _Fbyte_code(0x326b0f4,0x25b508,0xb,0xffffff,0x40240000,0x0) + 7ec
 >   _funcall_lambda(0x62f8b60,0x0,0xf7ffef34,0x2,0xf7fff6f8,0x0) + 3c8
 >   _Ffuncall(0x1,0xf7ffef30,0xcfc00,0x0,0x10,0xf7fff7dc) + 694
 >   _Fbyte_code(0x3265e78,0x258288,0x4,0xffffff,0xfffc00,0xf7ffed5c) + 7ec
 >   _funcall_lambda(0x62f8d20,0x0,0xf7fff19c,0x1,0x32,0xf82ec66c) + 3c8
 >   _Ffuncall(0x1,0xf7fff198,0xcfc00,0x0,0x8,0xf8483fb4) + 694
 >   _Fbyte_code(0x3265c98,0x2ec2a8,0x2,0xffffff,0xfffc00,0x12bf90) + 7ec
 >   _funcall_lambda(0x62ec140,0x1,0xf7fff54c,0x0,0x81010100,0xff0000) + 3c8
 >   _Ffuncall(0x2,0xf7fff548,0x0,0x0,0x0,0x0) + 694
 >   _Fcall_interactively(0x126e8e0,0x11b2c04,0x11b2c04,0xf7fff688,0xf7fff6f8,0xf7fff7dc) + 1998
 >   _Fcommand_execute(0x126e8e0,0x11b2c04,0x7000000,0xfffc00,0xf7fff6f8,0xf7fff7dc) + 24c
 >   _command_loop_1(0x189000,0xf7fff9c0,0x11b2d44,0x11b2c04,0xf7fff208,0xf7ffed5c) + e70
 >   _internal_condition_case(0x4688c,0x11b2d30,0x460a4,0x46000,0xf82ec66c,0x10000) + 10c
 >   _command_loop_2(0x11b2c04,0x46580,0xaf354,0x80,0x3,0x0) + 1c
 >   _internal_catch(0x11b2d1c,0x46580,0x11b2c04,0x46400,0x3,0x0) + bc
 >   _command_loop(0x187800,0x0,0x205810,0x640,0x3,0x0) + a0
 >   _recursive_edit_1(0x46018,0x11b2c04,0x46000,0x80,0x0,0x0) + 64
 >   _Frecursive_edit(0x187400,0x1,0x0,0x17d918,0x5,0x0) + c0
 >   _main(0x1,0xf7fffd9c,0xf7fffda4,0x187400,0x0,0x0) + 8dc
Next message: Michael Sperber [Mr. Preprocessor]: "1.9: Shouldn't + also make the directory show up?"
Previous message: jeff: "efs kills Jeff's brain (modtime bug *not* fixed)"