GNU bug report logs -
#6126
24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file
Previous Next
Reported by: Chunyu Wang <cymacs <at> gmail.com>
Date: Thu, 6 May 2010 16:20:03 UTC
Severity: normal
Found in version 24.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Chunyu Wang <cymacs <at> gmail.com>
> Date: Fri, 7 May 2010 00:08:08 +0800
> Cc:
>
> emacs -Q to start
> M-: (w32-shell-execute "open" "C:\\abc.ttt")
>
> Emacs got killed by system because of segmentation fault. The file C:/abc.ttt
> is just a text file with no system default associated program, and this should
> make a w32-shell-execute error in the *Message* buffer.
On my system, there's no segfault, only the (expected) error thrown:
Debugger entered--Lisp error: (error "ShellExecute failed: No application is associated with the specified file for this operation.
")
w32-shell-execute("open" "C:\\abc.ttt")
eval((w32-shell-execute "open" "C:\\abc.ttt"))
eval-expression((w32-shell-execute "open" "C:\\abc.ttt") nil)
call-interactively(eval-expression nil nil)
And from the backtrace you show, Emacs was trying to display the same
error in your case:
> #4 0x0100b463 in error (m=0x1349794 "ShellExecute failed: %s",
> a1=0x40008048 <Address 0x40008048 out of bounds>,
> a2=0x40008048 <Address 0x40008048 out of bounds>,
> a3=0x40008048 <Address 0x40008048 out of bounds>) at eval.c:2078
> used = 1073774664
> buf = "ShellExecute failed:
> \236\310\000\000\000\000\000\000\020\000\000\000\000\000\000,\212~\363\314\365\210\000\304\365\210\000\000\000\000\000\244\365\210\000\000\000\000\000H\274\000\001\030\000\000\000\260\365\210\000\202\236\000\000\244\364\210\000\311\237\312t\304\377\210\000\035\004hw\235\254!\003\376\377\377\377\372\066dw\362\062dw`\236\310\000h\236\310\000H\274\067\001h\236\310\000\030\000\000\000`\236\310\000\330\365\210\000)>\275u\000\000\306\000\000\000\000\000h\236\310\000
> \001e\004\032x\275\002\002\000\000\000\030\000\364\001H\274\067\001\032\000\034\000h\236\310\000\000\000\000\000\b\366\210\000\323\377\a\001\000\000\000\000\000\000\000"
> size = 200
> buffer = 0x88f520 "ShellExecute failed: \236\310"
> args = {
> 0x137bc48
> "\317\265\315\263\325\322\262\273\265\275\326\270\266\250\265\304\316\304\274\376\241\243\r\n",
> 0x465fc78 "C:\\abc.ttt", 0x0}
So I think the problem is not related to the fact that the file's
extension was unassociated, but rather that the file name used some
non-ASCII characters that Emacs tried to display, and crashed because
some table was invalid, or something like that. Observe:
> Program received signal SIGSEGV, Segmentation fault.
> 0x01129096 in char_table_ref (table=47436805, c=16390349) at chartab.c:210
> 210 if (SUB_CHAR_TABLE_P (val))
> (gdb) p val
> $1 = 1073774669
> (gdb) bt full
> #0 0x01129096 in char_table_ref (table=47436805, c=16390349) at chartab.c:210
> tbl = 0x2d3d400
> val = 1073774669
> #1 0x011185ab in c_string_width (
> str=0x137bc48
> "\317\265\315\263\325\322\262\273\265\275\326\270\266\250\265\304\316\304\274\376\241\243\r\n",
> len=24, precision=-1, nchars=0x0,
> nbytes=0x0) at character.c:420
> bytes = 5
> thiswidth = 1073774664
> val = 1073774669
> c = 16390349
> i = 7
> i_byte = 18
> width = 6
> dp = 0x2db7200
> #2 0x0111870b in strwidth (
> str=0x40008048 <Address 0x40008048 out of bounds>, len=1073774664)
> at character.c:453
> No locals.
> #3 0x0114386d in doprnt (buffer=0x88f520 "ShellExecute failed: \236\310",
So it dies inside a call to char_table_ref, evidently trying to
compute the width of a string.
Does this problem happen in an unoptimized build as well? If so,
could you please find out what is the table it is using (the `tbl'
variable in frame #0), and also what is `val' (by using the xtype
command and a command to show the Lisp type printed by xtype, probably
xchartable)?
This bug report was last modified 15 years and 23 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.