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
Message #20 received at 6126 <at> debbugs.gnu.org (full text, mbox):
On Fri, May 7, 2010 at 11:27 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman <at> gmail.com>
>> Date: Fri, 7 May 2010 02:00:49 +0200
>> Cc: 6126 <at> debbugs.gnu.org
>>
>> - 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?
>
> Yes. DWORD is an unsigned 32-bit integer type on all versions of
> Windows, even on 64-bit Windows. (I agree that it would be better to
> use `unsigned int' rather than just `int', though.)
Hi Eli,
Wouldn't it be better to just use DWORD which is what is used in the
ms docs for GetLastError etc? Maybe that would confuse newcomers quite
a bit less?
>> - The call to error in w32-shell-execute has only two arguments. Is
>> that correct?
>
> Yes, the other arguments are optional, see the doc string.
>
>> error in eval.c takes four arguments.
>
> `error' accepts a variable-size argument list, like `printf'. This is
> stated in the commentary in eval.c.
Oh, sorry. Thanks.
>> - The parameter lpBuffer to FormatMessage has the type LPTSTR. Is it
>> correct to call that with *char (ie buf)?
>
> Yes. LPTSTR is defined as a `char *' in non-Unicode builds, and as a
> `wchar_t *' in Unicode builds (which we don't yet support in Emacs,
> but we should, some day).
When that has been done I think using LPTSTR would be best. Maybe
putting a note there why it is not LPTSTR today would be good?
>> It looks in the backtrace
>> like even the argument a1 to error is incorrect.
>
> If you mean these parts of the backtrace:
>
> 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
>
> then it looks like `error' handles that just fine, because the value
> of `args[]' computed from them is correct:
It just looked strange to me that they all three have the same value.
Is that how it normally looks then a2 and a3 are not given?
> 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}
>
> Maybe the problem happens because the error string (args[0]) is
> encoded in a locale-specific encoding, so perhaps calling build_string
> on it is not TRT.
I guess it is sometning with the encoding, but I really have no more
accurate idea of it.
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.