bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open


From: Eli Zaretskii
Subject: bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file
Date: Fri, 07 May 2010 12:03:06 +0300

> From: Chunyu Wang <cymacs@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)?






reply via email to

[Prev in Thread] Current Thread [Next in Thread]