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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12933 in the body.
You can then email your comments to 12933 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michel de Ruiter <mdruiter <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Hard space and w32-downcase-file-names: crash
Date: Mon, 19 Nov 2012 14:48:13 +0100

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.

Message #10 received at 12933-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: mdruiter <at> gmail.com
Cc: 12933-done <at> debbugs.gnu.org
Subject: Re: bug#12933: 24.3.50; Hard space and w32-downcase-file-names: crash
Date: Mon, 19 Nov 2012 19:05:00 +0200

> From: Michel de Ruiter <mdruiter <at> 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.

Message #13 received at 12933-done <at> debbugs.gnu.org (full text, mbox):

From: Michel de Ruiter <mdruiter <at> gmail.com>
To: gnu.emacs.bug <at> googlegroups.com
Cc: Eli Zaretskii <eliz <at> gnu.org>, 12933-done <at> debbugs.gnu.org,
	mdruiter <at> gmail.com
Subject: Re: bug#12933: 24.3.50; Hard space and w32-downcase-file-names: crash
Date: Tue, 4 Dec 2012 06:04:03 -0800 (PST)

> 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

Message #16 received at 12933 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michel de Ruiter <mdruiter <at> gmail.com>
Cc: 12933 <at> debbugs.gnu.org
Subject: Re: bug#12933: 24.3.50; Hard space and w32-downcase-file-names: crash
Date: Tue, 04 Dec 2012 20:49:53 +0200

> Date: Tue, 4 Dec 2012 06:04:03 -0800 (PST)
> From: Michel de Ruiter <mdruiter <at> gmail.com>
> Cc: mdruiter <at> gmail.com, 12933-done <at> debbugs.gnu.org, 
> 	Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.