bug#12933: 24.3.50; Hard space and w32-downcase-file-names: crash

bug#12933: 24.3.50; Hard space and w32-downcase-file-names: crash

[Michel de Ruiter]

Hi all,

I have found a bug in Emacs on Windows (NTEmacs).

The easiest way to reproduce the crash is:
- start emacs -Q
- type M-:
- type (setq w32-downcase-file-names t)
- type RET
- type C-x C-f
- type C-q 2 4 0 RET
This shows the "Emacs Abort Dialog" ("A fatal error has occurred!").

I don't have gdb to further debug this.
I saw it in GNU Emacs 24.0.96.1 (i386-mingw-nt6.1.7601) of 2012-04-29
on MARVIN, on Windows 7 Enterprise SP1 (x64, version 6.1.7601). It has
been confirmed in recent build 24.3.50 as well.

As suggested by Eli Zaretskii and others, I'm reporting it here.

Groente, Michel.

bug#12933: 24.3.50; Hard space and w32-downcase-file-names: crash

[Eli Zaretskii]

> From: Michel de Ruiter <mdruiter@gmail.com>
> Date: Mon, 19 Nov 2012 14:48:13 +0100
> 
> I have found a bug in Emacs on Windows (NTEmacs).
> 
> The easiest way to reproduce the crash is:
> - start emacs -Q
> - type M-:
> - type (setq w32-downcase-file-names t)
> - type RET
> - type C-x C-f
> - type C-q 2 4 0 RET
> This shows the "Emacs Abort Dialog" ("A fatal error has occurred!").
> 
> I don't have gdb to further debug this.
> I saw it in GNU Emacs 24.0.96.1 (i386-mingw-nt6.1.7601) of 2012-04-29
> on MARVIN, on Windows 7 Enterprise SP1 (x64, version 6.1.7601). It has
> been confirmed in recent build 24.3.50 as well.

Thanks, this was fixed in revision 110912 on the emacs-24 branch.

bug#12933: 24.3.50; Hard space and w32-downcase-file-names: crash

[Michel de Ruiter]

> Thanks, this was fixed in revision 110912 on the emacs-24 branch.

I tested this (in emacs-24-r110985-2012.12.03-w32-i386) and indeed, this specific situation is fixed. Whether I type 2 4 0 (not hard space after all) or 1 6 0 (which I think I meant from the beginning).

But if I type RET *again* (after quoted-inserting only the single character), to open a new file with that name, I still get a crash.

A stack trace is below.

Or should I report this as a separate bug?

Groente, Michel.

#0  0x76b5321a in KERNELBASE!DeleteAce ()
   from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
#1  0x0115540f in emacs_abort () at w32fns.c:7717
#2  0x01251ce8 in multibyte_chars_in_text (
    ptr=0x88d892 "\342\240/.dir-locals.el", nbytes=33) at character.c:539
#3  0x01019e1c in make_specified_string (
    contents=0x88d882 "d:/Users/Michel/\342\240/.dir-locals.el", nchars=-1,
    nbytes=33, multibyte=true) at alloc.c:2141
#4  0x01059fb9 in Fexpand_file_name (name=87422977,
    default_directory=87397937) at fileio.c:1323
#5  0x01014f27 in Ffuncall (nargs=3, args=0x88da48) at eval.c:2777
#6  0x010e1b67 in exec_byte_code (bytestr=20301185, vector=20301269,
    maxdepth=20, args_template=57362458, nargs=0, args=0x0) at bytecode.c:899
#7  0x01015e41 in funcall_lambda (fun=20301149, nargs=2, arg_vector=0x36b481a)
    at eval.c:3006
#8  0x010152da in Ffuncall (nargs=3, args=0x88dd44) at eval.c:2823
#9  0x010e1b67 in exec_byte_code (bytestr=20330841, vector=20330965,
    maxdepth=40, args_template=57362458, nargs=0, args=0x0) at bytecode.c:899
#10 0x01015e41 in funcall_lambda (fun=20330813, nargs=1, arg_vector=0x36b481a)
    at eval.c:3006
#11 0x010152da in Ffuncall (nargs=2, args=0x88e054) at eval.c:2823
#12 0x010e1b67 in exec_byte_code (bytestr=20331705, vector=20331821,
    maxdepth=20, args_template=57362458, nargs=0, args=0x0) at bytecode.c:899
#13 0x01015e41 in funcall_lambda (fun=20331677, nargs=0, arg_vector=0x36b481a)
    at eval.c:3006
#14 0x0101561b in apply_lambda (fun=20331677, args=57362458) at eval.c:2883
#15 0x010135f0 in eval_sub (form=20327014) at eval.c:2184
#16 0x01010dbf in internal_lisp_condition_case (var=59206018,
    bodyform=20327014, handlers=20327022) at eval.c:1242
#17 0x010e27a4 in exec_byte_code (bytestr=20326385, vector=20326709,
    maxdepth=24, args_template=57362458, nargs=0, args=0x0) at bytecode.c:1095
#18 0x01015e41 in funcall_lambda (fun=20326357, nargs=0, arg_vector=0x36b481a)
    at eval.c:3006
#19 0x0101561b in apply_lambda (fun=20326357, args=57362458) at eval.c:2883
#20 0x010135f0 in eval_sub (form=20316638) at eval.c:2184
#21 0x01010dbf in internal_lisp_condition_case (var=59206018,
    bodyform=20316638, handlers=20316646) at eval.c:1242
#22 0x010e27a4 in exec_byte_code (bytestr=20316305, vector=20316413,
    maxdepth=16, args_template=57362458, nargs=0, args=0x0) at bytecode.c:1095
#23 0x01015e41 in funcall_lambda (fun=20316261, nargs=1, arg_vector=0x36b481a)
    at eval.c:3006
#24 0x010152da in Ffuncall (nargs=2, args=0x88ec74) at eval.c:2823
#25 0x010e1b67 in exec_byte_code (bytestr=20315297, vector=20315565,
    maxdepth=20, args_template=57362458, nargs=0, args=0x0) at bytecode.c:899
#26 0x01015e41 in funcall_lambda (fun=20315221, nargs=2, arg_vector=0x36b481a)
    at eval.c:3006
#27 0x010152da in Ffuncall (nargs=3, args=0x88ef74) at eval.c:2823
#28 0x010e1b67 in exec_byte_code (bytestr=20313089, vector=20313269,
    maxdepth=12, args_template=57362458, nargs=0, args=0x0) at bytecode.c:899
#29 0x01015e41 in funcall_lambda (fun=20313021, nargs=6, arg_vector=0x36b481a)
    at eval.c:3006
#30 0x010152da in Ffuncall (nargs=7, args=0x88f264) at eval.c:2823
#31 0x010e1b67 in exec_byte_code (bytestr=20311889, vector=20312253,
    maxdepth=32, args_template=57362458, nargs=0, args=0x0) at bytecode.c:899
#32 0x01015e41 in funcall_lambda (fun=20311829, nargs=4, arg_vector=0x36b481a)
    at eval.c:3006
#33 0x010152da in Ffuncall (nargs=5, args=0x88f574) at eval.c:2823
#34 0x010e1b67 in exec_byte_code (bytestr=20306673, vector=20306733,
    maxdepth=24, args_template=57362458, nargs=0, args=0x0) at bytecode.c:899
#35 0x01015e41 in funcall_lambda (fun=20306621, nargs=2, arg_vector=0x36b481a)
    at eval.c:3006
#36 0x010152da in Ffuncall (nargs=3, args=0x88f870) at eval.c:2823
#37 0x010140c3 in Fapply (nargs=2, args=0x88f8f4) at eval.c:2308
#38 0x01014627 in apply1 (fn=59099570, arg=87380126) at eval.c:2542
#39 0x010e58d9 in Fcall_interactively (function=59099570,
    record_flag=57362458, keys=57383853) at callint.c:377
#40 0x01014f98 in Ffuncall (nargs=4, args=0x88fb30) at eval.c:2781
#41 0x010146f6 in call3 (fn=57473770, arg1=59099570, arg2=57362458,
    arg3=57362458) at eval.c:2599
#42 0x01052d9e in Fcommand_execute (cmd=59099570, record_flag=57362458,
    keys=57362458, special=57362458) at keyboard.c:10240
#43 0x010391b3 in command_loop_1 () at keyboard.c:1586
#44 0x01010ea1 in internal_condition_case (bfun=0x103847e <command_loop_1>,
    handlers=57413018, hfun=0x1037c9d <cmd_error>) at eval.c:1288
#45 0x010380f7 in command_loop_2 (ignore=57362458) at keyboard.c:1167
#46 0x010108fe in internal_catch (tag=57402874,
    func=0x10380d3 <command_loop_2>, arg=57362458) at eval.c:1059
#47 0x010380b1 in command_loop () at keyboard.c:1146
#48 0x0103766b in recursive_edit_1 () at keyboard.c:778
#49 0x01037998 in Frecursive_edit () at keyboard.c:842
#50 0x01002920 in main (argc=1, argv=0x31a68) at emacs.c:1547

bug#12933: 24.3.50; Hard space and w32-downcase-file-names: crash

[Eli Zaretskii]

> Date: Tue, 4 Dec 2012 06:04:03 -0800 (PST)
> From: Michel de Ruiter <mdruiter@gmail.com>
> Cc: mdruiter@gmail.com, 12933-done@debbugs.gnu.org, 
> 	Eli Zaretskii <eliz@gnu.org>
> 
> > Thanks, this was fixed in revision 110912 on the emacs-24 branch.
> 
> I tested this (in emacs-24-r110985-2012.12.03-w32-i386) and indeed, this specific situation is fixed. Whether I type 2 4 0 (not hard space after all) or 1 6 0 (which I think I meant from the beginning).
> 
> But if I type RET *again* (after quoted-inserting only the single character), to open a new file with that name, I still get a crash.
> 
> A stack trace is below.
> 
> Or should I report this as a separate bug?

No, it's another incarnation of the same bug.  Fixed in revision
110988 on the emacs-24 branch.

Thanks.