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

From: Lennart Borgman <[email-masked]>
Date: Fri, 7 May 2010 02:00:49 +0200

On Thu, May 6, 2010 at 6:08 PM, Chunyu Wang <[email-masked]> wrote:
>
> 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. The following is the
> mingw gdb backtraces.
>
> GNU gdb (GDB) 7.1
...
> #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 ...

I do not understand C code but here are some small observations:

- In w32_error the argument error_no has type int. It should be more
easy to understand if it had the type DWORD which is what GetLastError
returns. Will using int be correct on all w32 platforms?

- The call to error in w32-shell-execute has only two arguments. Is
that correct? error in eval.c takes four arguments.

- The parameter lpBuffer to FormatMessage has the type LPTSTR. Is it
correct to call that with *char (ie buf)? It looks in the backtrace
like even the argument a1 to error is incorrect.