* bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file
@ 2010-05-06 16:08 Chunyu Wang
2010-05-07 0:00 ` Lennart Borgman
2010-05-07 9:03 ` Eli Zaretskii
0 siblings, 2 replies; 13+ messages in thread
From: Chunyu Wang @ 2010-05-06 16:08 UTC (permalink / raw)
To: 6126
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug. If you can, give
a recipe starting from `emacs -Q':
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
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from C:\free_ware\emacs-bzr\src\oo-spd\i386/emacs.exe...done.
(gdb) run -Q
Starting program: C:\free_ware\emacs-bzr\src\oo-spd\i386/emacs.exe -Q
[New Thread 3204.0x1304]
[New Thread 3204.0x1338]
[New Thread 3204.0x134c]
[New Thread 3204.0x108]
[New Thread 3204.0x13f8]
[New Thread 3204.0x13ec]
[New Thread 3204.0xfe8]
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",
bufsize=178,
format=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",
format_end=0x13497ab "", nargs=3,
args=0x88f510) at doprnt.c:213
size_bound = 0
width = 2003054591
cnt = 1
fmt = 0x13497ab ""
bufptr = 0x88f535 "\236\310"
tembuf =
"\304\000\306\000\370;\310\000\370\003\000\000\177\000\000\000(\364\210\000\000\000\306\000&\252iwp\236\310\000p\021\000\000\372\066dwE\236\312t\000\000\000\000\000\000\306\000h\236\310\000\364\300fw\350\242S\004p\036S\004\000\000\000\000q\000\004u\000\000\000\000\b\365\210\000\000\000\000\000P\001\306\000\000\000\306\000\336\363cwP\001\306\000\304\000\306\000\000\000\000\000\001\000S\004\000\000\000\000\001\000\000\000\001\000\000\000\000\000\274u\177\000\000\000\004\000\000\000\002\000\000\000\000\000\274\000\004\b\000\000\370;\310\000\004\000\000\000\370\003\000\000\000\000\000\000\330\364\210\000S5ew\177\000\000\000\000\000\000\000X$\300u\000\000\000\000\336\363cwP\001\306\000\000\000"...
size_allocated = 408
sprintf_buffer = 0x88f320 "\304"
big_buffer = 0x0
tem = 24
string = 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"
fixed_buffer =
"p\r\000\000\356\376\356\376\000\000\306\000`\236\310\000\000\000\000"
fmtcpy = 0x88f280 "%s"
minlen = 0
charbuf = "\201\034ew\000"
#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}
allocated = 0
string = 200
#5 0x0116332f in Fw32_shell_execute (operation=73728336, document=73728256,
parameters=45971482, show_flag=45971482) at w32fns.c:6356
current_dir = 73728288
#6 0x0100bbcb in Feval (form=20121176) at eval.c:2423
numargs = 2
args_left = 45971482
i = 4
maxargs = 4
argvals = {73728337, 73728321, 45971482, 45971482, 7, 5, 18825454,
46130778}
fun = 20121176
val = 1073774669
original_fun = 46186146
original_args = 48068942
funcar = 1073774669
backtrace = {next = 0x88f740, function = 0x88f67c, args = 0x88f680,
nargs = 2, evalargs = 1 '\001', debug_on_exit = 0 '\000'}
gcpro1 = {next = 0x2c360c2, var = 0x88f6a0, nvars = 7}
gcpro2 = {next = 0x2bfe4da, var = 0x2bd781a, nvars = 45971482}
gcpro3 = {next = 0x11f40f1, var = 0x88f680, nvars = 4}
#7 0x0100c622 in Ffuncall (nargs=2, args=0x118fa78) at eval.c:3072
fun = 18414200
original_fun = 8976276
funcar = 1073774669
lisp_numargs = 1073774664
val = 1073774669
backtrace = {next = 0x88f8b0, function = 0x88f790, args = 0x88f794,
nargs = 1, evalargs = 0 '\000', debug_on_exit = 0 '\000'}
internal_args = 0x88f794
i = 1073774669
#8 0x011217ac in Fbyte_code (bytestr=1073774669, vector=8976272, maxdepth=1)
at bytecode.c:680
op = 1
vectorp = 0x11f4050
stack = {pc = 0x12f154f "\nB\022\r\023)\f\v=\204&", top = 0x88f794,
bottom = 0x88f790, byte_string = 18825273,
byte_string_start = 0x12f1537 "\b\204\r", constants = 18825293,
next = 0x0}
top = 0x88f790
#9 0x0100c01d in funcall_lambda (fun=18825221, nargs=2, arg_vector=0x88f904)
at eval.c:3259
val = 1073774664
syms_left = 45971482
next = 18825216
i = 2
optional = 1
rest = 0
#10 0x0100c401 in Ffuncall (nargs=3, args=0x11f4005) at eval.c:3129
fun = 18825221
original_fun = 46442690
funcar = 1073774669
lisp_numargs = 1073774664
val = 1073774669
backtrace = {next = 0x88fb30, function = 0x88f900, args = 0x88f904,
nargs = 2, evalargs = 0 '\000', debug_on_exit = 0 '\000'}
internal_args = 0x2c4a8c2
i = 1073774669
#11 0x0100ce7a in Fapply (nargs=2, args=0x88f978) at eval.c:2570
i = 3
numargs = 2
spread_arg = 45971482
funcall_args = 0x88f900
fun = 18825221
gcpro1 = {next = 0x3, var = 0x0, nvars = 3}
#12 0x0100cfcb in apply1 (fn=46442690, arg=1073774669) at eval.c:2839
args = {46442690, 48069150}
gcpro1 = {next = 0x1056b87, var = 0x88f978, nvars = 2}
#13 0x0111f5b2 in Fcall_interactively (function=46442690,
record_flag=45971482, keys=45992709) at callint.c:396
specs = 48069150
filter_specs = 46442690
teml = 46442690
up_event = 45971482
enable = 45971482
next_event = 18111393
prefix_arg = 45971482
string = 0x2bf8212 ""
tem = 0x2be2362 ""
i = 45971482
j = 45971482
foo = 1073774664
prompt1 =
"\001\000\000\000\374\372\210\000\b\373\210\000\310\376\f\001\032x\275\002\001\000\000\000\001\000\000\000`\330\353\002\000\020\276\002\374\372\210\000\270\372\210\000H\372\030\001\000\000\000\000\370\372\210\000\374\372\210\000\001\000\000\000\000\000\000\000\372\031\300\002\330\372\210\000\324\\\000\001Xz8\001\000\000\000\000\000\000\000\000\002\000\000\000\302\250\304\002"
arg_from_tty = 0
gcpro1 = {next = 0x2bf80c2, var = 0x118fa48, nvars = 8977112}
gcpro2 = {next = 0x0, var = 0x2be253a, nvars = 50332722}
gcpro3 = {next = 0x1, var = 0x88fafc, nvars = 8977000}
gcpro4 = {next = 0x2c3d88e, var = 0x2be256a, nvars = 8976984}
gcpro5 = {next = 0x2be2e42, var = 0x2bd4d4e, nvars = 8977000}
key_count = 1
record_then_fail = 0
save_this_command = 46442690
save_last_command = 45971482
save_this_original_command = 46442690
save_real_this_command = 46442690
#14 0x0100c5fb in Ffuncall (nargs=4, args=0x132f190) at eval.c:3078
fun = 20115856
original_fun = 8977284
funcar = 1073774669
lisp_numargs = 1073774664
val = 1073774669
backtrace = {next = 0x0, function = 0x88fb80, args = 0x88fb84,
nargs = 3, evalargs = 0 '\000', debug_on_exit = 0 '\000'}
internal_args = 0x88fb84
i = 1073774669
#15 0x0100c825 in call3 (fn=1073774664, arg1=1073774664, arg2=1073774664,
arg3=1073774664) at eval.c:2900
ret_ungc_val = 1073774664
gcpro1 = {next = 0x2bf66ba, var = 0x2bd781a, nvars = 4}
args = {46117394, 46442690, 45971482, 45971482}
#16 0x0105c568 in Fcommand_execute (cmd=46442690, record_flag=45971482,
keys=1073774664, special=45971482) at keyboard.c:10397
final = 18825216
tem = 1073774669
prefixarg = 45971482
#17 0x010635b4 in command_loop_1 () at keyboard.c:1755
cmd = 2
keybuf = {536871144, 8977724, 0, 8977784, 8977720, 0, 33689212,
5181052, 0, 8977704, 8977708, 0, 0, 8977704, 0, 33689241, 5508761,
0, 245, 0, 0, 8977484, 8977312, 0, 1975451648, 13035872,
2003123744, 1959433885, 8977700, 13013560}
i = 1
prev_modiff = 10
prev_buffer = 0x2be1000
#18 0x0100a122 in internal_condition_case (bfun=0x1063281 <command_loop_1>,
handlers=46029042, hfun=0x105d002 <cmd_error>) at eval.c:1509
val = 1073774664
c = {tag = 45971482, val = 45971482, next = 0x88fdd0, gcpro = 0x0,
jmp = {8977816, 0, 20431289, 1, 8977644, 16818383, 8978372, 0,
1979200060, 1979200144, -1, 1975293735, -480, 7602240, 7471226,
7536741}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0,
pdlcount = 2, poll_suppress_count = 0, interrupt_input_blocked = 0,
byte_stack = 0x0}
h = {handler = 46029042, var = 45971482, chosen_clause = 0,
tag = 0x88fd20, next = 0x0}
#19 0x01056e52 in command_loop_2 () at keyboard.c:1356
val = 1073774664
#20 0x0100a057 in internal_catch (tag=1073774664,
func=0x1056e2f <command_loop_2>, arg=45971482) at eval.c:1245
c = {tag = 46027210, val = 45971482, next = 0x0, gcpro = 0x0, jmp = {
8977992, 0, 20431289, 1, 8977852, 16818237, 8978372, 0, 0,
1975450067, 0, 0, 8977948, 1978573890, 1979187344, 0},
backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0,
pdlcount = 2, poll_suppress_count = 0, interrupt_input_blocked = 0,
byte_stack = 0x0}
#21 0x01056c5f in command_loop () at keyboard.c:1335
No locals.
#22 0x01056cf8 in recursive_edit_1 () at keyboard.c:950
val = 0
#23 0x01056e19 in Frecursive_edit () at keyboard.c:1012
buffer = 45971482
#24 0x01002ed5 in main (argc=2, argv=0x310c0) at emacs.c:1784
dummy = 54
stack_bottom_variable = 1 '\001'
do_initial_setlocale = 1
skip_args = 0
no_loadup = 0
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x1188e50 "U\211\345\203\354\b\241\354\025\063\001\213"
(gdb) qu quit
A debugging session is active.
Inferior 1 [process 3204] will be killed.
Quit anyway? (y or n) error return ../../gdb-7.1/gdb/windows-nat.c:1162 was 5
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
c:/free_ware/emacs-bzr/etc/DEBUG.
In GNU Emacs 24.0.50.1 (i386-mingw-nt6.1.7600)
of 2010-05-06 on NCCY-PC
Windowing system distributor `Microsoft Corp.', version 6.1.7600
configured using `configure --with-gcc (3.4)'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: zh_CN
value of $XMODIFIERS: nil
locale-coding-system: cp936
default enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
M-x b <backspace> e m a c s SPC b u SPC <M-backspace>
<M-backspace> b u SPC <M-backspace> r e p o r t SPC
b u SPC SPC <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader emacsbug
help-mode easymenu view china-util tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mldrag mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev button minibuffer
faces cus-face files text-properties overlay md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process multi-tty emacs)
--
Harbin Institute of Technology, China
Chunyu Wang
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file
2010-05-06 16:08 bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file Chunyu Wang
@ 2010-05-07 0:00 ` Lennart Borgman
2010-05-07 1:52 ` Chunyu Wang
2010-05-07 9:27 ` Eli Zaretskii
2010-05-07 9:03 ` Eli Zaretskii
1 sibling, 2 replies; 13+ messages in thread
From: Lennart Borgman @ 2010-05-07 0:00 UTC (permalink / raw)
To: Chunyu Wang; +Cc: 6126
On Thu, May 6, 2010 at 6:08 PM, Chunyu Wang <cymacs@gmail.com> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file
2010-05-07 0:00 ` Lennart Borgman
@ 2010-05-07 1:52 ` Chunyu Wang
2010-05-07 9:27 ` Eli Zaretskii
1 sibling, 0 replies; 13+ messages in thread
From: Chunyu Wang @ 2010-05-07 1:52 UTC (permalink / raw)
To: Lennart Borgman; +Cc: 6126
2010/5/7 Lennart Borgman <lennart.borgman@gmail.com>:
> ...
> 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?
Sorry, I have no idea completely.
> - The call to error in w32-shell-execute has only two arguments. Is
> that correct? error in eval.c takes four arguments.
(w32-shell-execute OPERATION DOCUMENT &optional PARAMETERS SHOW-FLAG)
The last two are optional, but emacs crashed even if called with them.
> - 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.
no idea too.
--
Harbin Institute of Technology, China
Chunyu Wang
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file
2010-05-06 16:08 bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file Chunyu Wang
2010-05-07 0:00 ` Lennart Borgman
@ 2010-05-07 9:03 ` Eli Zaretskii
2010-05-07 12:17 ` Chunyu Wang
2010-05-07 14:21 ` Chunyu Wang
1 sibling, 2 replies; 13+ messages in thread
From: Eli Zaretskii @ 2010-05-07 9:03 UTC (permalink / raw)
To: Chunyu Wang; +Cc: 6126
> 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)?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file
2010-05-07 0:00 ` Lennart Borgman
2010-05-07 1:52 ` Chunyu Wang
@ 2010-05-07 9:27 ` Eli Zaretskii
2010-05-07 10:52 ` Lennart Borgman
1 sibling, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2010-05-07 9:27 UTC (permalink / raw)
To: Lennart Borgman; +Cc: 6126, cymacs
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Fri, 7 May 2010 02:00:49 +0200
> Cc: 6126@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.)
> - 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.
> - 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).
> 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:
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file
2010-05-07 9:27 ` Eli Zaretskii
@ 2010-05-07 10:52 ` Lennart Borgman
0 siblings, 0 replies; 13+ messages in thread
From: Lennart Borgman @ 2010-05-07 10:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 6126, cymacs
On Fri, May 7, 2010 at 11:27 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Fri, 7 May 2010 02:00:49 +0200
>> Cc: 6126@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file
2010-05-07 9:03 ` Eli Zaretskii
@ 2010-05-07 12:17 ` Chunyu Wang
2010-05-07 14:21 ` Chunyu Wang
1 sibling, 0 replies; 13+ messages in thread
From: Chunyu Wang @ 2010-05-07 12:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 6126
2010/5/7 Eli Zaretskii <eliz@gnu.org>:
> 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:
Indeed. After I change the system(win7-ultimate-64bit) language to
English, the crash is gone.
Emacs got the expected error and pop up a *backtrace* buffer with the following.
Debugger entered--Lisp error: (void-function w32-shell-exec)
(w32-shell-exec "open" "D:\\a.xyz")
eval((w32-shell-exec "open" "D:\\a.xyz"))
eval-expression((w32-shell-exec "open" "D:\\a.xyz") nil)
call-interactively(eval-expression nil nil)
And if w32-shell-execute called in an elisp function, *Message* buffer
got the error:
if: ShellExecute failed: No application is associated with the
specified file for this operation.
> 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)?
I'll try to figure it out.
--
Harbin Institute of Technology, China
Chunyu Wang
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file
2010-05-07 9:03 ` Eli Zaretskii
2010-05-07 12:17 ` Chunyu Wang
@ 2010-05-07 14:21 ` Chunyu Wang
2010-05-07 15:12 ` Eli Zaretskii
1 sibling, 1 reply; 13+ messages in thread
From: Chunyu Wang @ 2010-05-07 14:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 6126
2010/5/7 Eli Zaretskii <eliz@gnu.org>:
> 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)?
Crashed as before for an unoptimized build one. The following is my tracing and
information about `tbl' and `val'. If need some other thing, just tell
me how to get it.
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from C:\free_ware\emacs-bzr\src/oo\i386\emacs.exe...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not
from terminal]
Environment variable "DISPLAY" not defined.
Environment variable "TERM" not defined.
Breakpoint 1 at 0x11d0641: file w32fns.c, line 7349.
Temporary breakpoint 2 at 0x10c0d81: file sysdep.c, line 1039.
(gdb) run -Q --eval "(w32-shell-execute \"open\" \"D:\\abc.ttt\")"
Starting program: C:\free_ware\emacs-bzr\src/oo\i386\emacs.exe -Q
--eval "(w32-shell-execute \"open\" \"D:\\abc.ttt\")"
[New Thread 3848.0x7e4]
[New Thread 3848.0x184]
[New Thread 3848.0xcb4]
[New Thread 3848.0x88c]
Program received signal SIGSEGV, Segmentation fault.
0x01176ce6 in char_table_ref (table=48448005, c=16331833) at chartab.c:210
210 if (SUB_CHAR_TABLE_P (val))
(gdb) p tbl
$1 = (struct Lisp_Char_Table *) 0x2e34200
(gdb) p *tbl
$2 = {
size = 1073774666,
next = 0x2e34600,
defalt = 46147610,
parent = 46147610,
purpose = 46298426,
ascii = 46147610,
contents = {71655429, 46147610 <repeats 63 times>},
extras = {46147610}
}
(gdb) p val
$3 = 762605157
(gdb) xtype val
Lisp_Vectorlike
Cannot access memory at address 0x2d746e60
(gdb) bt full
#0 0x01176ce6 in char_table_ref (table=48448005, c=16331833) at chartab.c:210
tbl = 0x2e34200
val = 762605157
#1 0x01047e85 in disp_char_vector (dp=0x2e34200, c=16331833) at xdisp.c:12602
table = 48448005
val = 16331833
#2 0x01160998 in c_string_width (
str=0x13e3c28
"\303\273\323\320\323\246\323\303\263\314\320\362\323\353\264\313\262\331\327\367\265\304\326\270\266\250\316\304\274\376\323\320\271\330\301\252\241\243\r\n",
len=40, precision=-1, nchars=0x0, nbytes=0x0)
at character.c:412
bytes = 5
thiswidth = 1
val = 46147610
c = 16331833
i = 10
i_byte = 28
width = 11
dp = 0x2e34200
#3 0x01160d70 in strwidth (
str=0x13e3c28
"\303\273\323\320\323\246\323\303\263\314\320\362\323\353\264\313\262\331\327\367\265\304\326\270\266\250\316\304\274\376\323\320\271\330\301\252\241\243\r\n",
len=40) at character.c:453
No locals.
#4 0x011a111f in doprnt (
buffer=0x88f220 "ShellExecute failed: R\033\366\274\362\210",
bufsize=178, format=0x13b1272 "ShellExecute failed: %s",
format_end=0x13b1289 "", nargs=3, args=0x88f200) at doprnt.c:213
size_bound = 358
width = 2011558878
cnt = 1
fmt = 0x13b1289 ""
bufptr = 0x88f235 "R\033\366\274\362\210"
tembuf =
"\320\357\250\000\320@\250\000\370\003\000\000\177\000\000\000\030\361\210\000\000\000\246\000&\252\353w\030\034\250\000@\v\000\000\372\066\346w\223\002\037u\000\000\000\000\000\000\246\000\370\035\250\000\204\000\004\200\350\242;!\002\000\004\006\000\000\000\000\250\004\004\250\000\000\000\000\370\361\210\000\000\000\000\000P\001\246\000\000\000\246\000\336\363\345wP\001\246\000\320\357\250\000\000\000\000\000\001\000;!\000\000\000\000\001\000\000\000\001\000\000\000\000\000\335u\177\000\000\000\004\000\000\000\002\000\000\000\000\000\335\000\004\b\000\000\320\357\250\000\003\000\000\000\370\003\000\000\000\000\000\000\310\361\210\000\003\002\004\005\177\000\000\000\000\000\000\000X$\341u\000\000\000\000\336\363\345wP\001\246\000"...
size_allocated = 408
sprintf_buffer = 0x88f010 "\320\357\250"
big_buffer = 0x0
tem = 40
string = 0x13e3c28
"\303\273\323\320\323\246\323\303\263\314\320\362\323\353\264\313\262\331\327\367\265\304\326\270\266\250\316\304\274\376\323\320\271\330\301\252\241\243\r\n"
fixed_buffer =
"\201\034\347w\000\000\246\000\310\243\353w\000\"\250\000X\005\000"
fmtcpy = 0x88ef50 "%s"
minlen = 0
charbuf = "\001\000\000\000\000"
#5 0x010212ff in error (m=0x13b1272 "ShellExecute failed: %s",
a1=0x13e3c28
"\303\273\323\320\323\246\323\303\263\314\320\362\323\353\264\313\262\331\327\367\265\304\326\270\266\250\316\304\274\376\323\320\271\330\301\252\241\243\r\n",
a2=0x2e57ea8 "D:\\abc.ttt", a3=0x0) at eval.c:2078
used = 4
buf = "ShellExecute failed:
R\033\366\274\362\210\000\264\362\210\000\000\000\000\000\224\362\210\000\000\000\000\000(<\000\001(\000\000\000\240\362\210\000\"\036\000\000\224\361\210\000\037\001\037u\304\377\210\000\035\004\352w{5r\002\376\377\377\377\372\066\346w\362\062\346w\360\035\250\000\370\035\250\000(<>\001\370\035\250\000(\000\000\000\360\035\250\000\310\362\210\000)>\336u\000\000\246\000\000\000\000\000\370\035\250\000\000\000\000\000\000\000\000\000\060\367\210\000(\000\364\001(<>\001*\000,\000\370\035\250\000\000\000\000\000\370\362\210\000\246[ \001\000\000\000\000\000\000\000\000\203\004\000\000\000\000\000\000(<>\001\364\001\000"
size = 200
mlen = 23
buffer = 0x88f220 "ShellExecute failed: R\033\366\274\362\210"
args = {
0x13e3c28
"\303\273\323\320\323\246\323\303\263\314\320\362\323\353\264\313\262\331\327\367\265\304\326\270\266\250\316\304\274\376\323\320\271\330\301\252\241\243\r\n",
0x2e57ea8 "D:\\abc.ttt", 0x0}
allocated = 0
string = 2005649611
#6 0x011ceb98 in Fw32_shell_execute (operation=71858641, document=71858577,
parameters=46147610, show_flag=46147610) at w32fns.c:6356
current_dir = 71858593
#7 0x01021dbd in Feval (form=48376582) at eval.c:2423
numargs = 8
args_left = 46147610
i = 4
maxargs = 4
argvals = {71858641, 71858625, 46147610, 46147610, 6, 21658032,
8975352, 18102244}
fun = 20545853
val = 46147610
original_fun = 46362274
original_args = 48376574
funcar = 17367327
backtrace = {
next = 0x88f480,
function = 0x88f424,
args = 0x88f390,
nargs = 2,
evalargs = 1 '\001',
debug_on_exit = 0 '\000'
}
gcpro1 = {
next = 0x44556e1,
var = 0x88f3f4,
nvars = 0
}
gcpro2 = {
next = 0xc,
var = 0x88f730,
nvars = 8975352
}
gcpro3 = {
next = 0x6,
var = 0x88f390,
nvars = 4
}
#8 0x01022cac in Ffuncall (nargs=2, args=0x88f4e0) at eval.c:3072
fun = 18838957
original_fun = 46281498
funcar = 19110065
numargs = 1
lisp_numargs = 17442686
val = 48376582
backtrace = {
next = 0x88f6d0,
function = 0x88f4e0,
args = 0x88f4e4,
nargs = 1,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = 0x88f4e4
i = 47609349
#9 0x0116cf4d in Fbyte_code (bytestr=19109169, vector=19109189, maxdepth=40)
at bytecode.c:680
count = 5
op = 1
vectorp = 0x1239548
bytestr_length = 1187
stack = {
pc = 0x1369433
"\210\202\300\003\016M\345\235\203\311\001\346\347\016O\206\241\001\f\211A\024@!!\026F\016E\203\274\001\016E\016F\016EAB\241\210\016EA\026E\202\300\003\016F\016SB\211\026S\026E\202\300\003\016M\350\235\203\372\001\347\016O\206\333\001\f\211A\024@!\036T\346\016T!\036U\351\016U!\203\357\001\016U\026T\352\016T\314\331#\210*\202\300\003\016M\353\235\203!\002\347\016O\206\f\002\f\211A\024@!\036T\346\016T!\036U\352\016U\314\331\211$\210*\202\300\003\016M\354\232\203J\002\331\026R\016O\206\065\002\f\211A\024@\211\026F;\204@\002\332\355!\210\356\347\016F!!\210\202\300\003\016M\357\232\203X\002\360"...,
top = 0x88f4e4,
bottom = 0x88f4e0,
byte_string = 19109169,
byte_string_start = 0x13692a9 "\306 \210\b\203\021",
constants = 19109189,
next = 0x88f850
}
top = 0x88f4e0
result = 55
#10 0x010233ea in funcall_lambda (fun=19109141, nargs=1, arg_vector=0x88f734)
at eval.c:3259
val = 46186501
syms_left = 46147610
next = 47396658
count = 4
i = 1
optional = 0
rest = 0
#11 0x01022ec9 in Ffuncall (nargs=2, args=0x88f730) at eval.c:3118
fun = 19109141
original_fun = 47410514
funcar = 46186501
numargs = 1
lisp_numargs = 16882677
val = 8976152
backtrace = {
next = 0x88f910,
function = 0x88f730,
args = 0x88f734,
nargs = 1,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = 0x88f6f8
i = 48196830
#12 0x0116cf4d in Fbyte_code (bytestr=19095513, vector=19095533, maxdepth=28)
at bytecode.c:680
count = 4
op = 1
vectorp = 0x1235ff0
bytestr_length = 1665
stack = {
pc = 0x136bf05 "\210\016N\203$\006\201\332",
top = 0x88f734,
bottom = 0x88f730,
byte_string = 19095513,
byte_string_start = 0x136b8ed "\306
\020\307\021\n\023\307\024\310\311!\211\035\307=\204\064",
constants = 19095533,
next = 0x88fa90
}
top = 0x88f730
result = 0
#13 0x010233ea in funcall_lambda (fun=19095493, nargs=0, arg_vector=0x88f974)
at eval.c:3259
val = 46903105
syms_left = 46147610
next = 46619562
count = 4
i = 0
optional = 0
rest = 0
#14 0x01022ec9 in Ffuncall (nargs=1, args=0x88f970) at eval.c:3118
fun = 19095493
original_fun = 47394986
funcar = 224
numargs = 0
lisp_numargs = 16882677
val = 8976728
backtrace = {
next = 0x88fc50,
function = 0x88f970,
args = 0x88f974,
nargs = 0,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = 0x88f938
i = 48277990
#15 0x0116cf4d in Fbyte_code (bytestr=19092985, vector=19093005, maxdepth=24)
at bytecode.c:680
count = 2
op = 0
vectorp = 0x1235610
bytestr_length = 220
stack = {
pc = 0x136c6af
"\210*\340\341\342\"\210\343\321\344\"\211\036$;\203\251",
top = 0x88f970,
bottom = 0x88f970,
byte_string = 19092985,
byte_string_start = 0x136c621 "\b\203\b",
constants = 19093005,
next = 0x0
}
top = 0x88f970
result = 243858076
#16 0x010233ea in funcall_lambda (fun=19092965, nargs=0, arg_vector=0x88fb20)
at eval.c:3259
val = 2011825181
syms_left = 46147610
next = 0
count = 2
i = 0
optional = 0
rest = 0
#17 0x010230d5 in apply_lambda (fun=19092965, args=46147610, eval_flag=1)
at eval.c:3183
args_left = 46147610
numargs = 0
arg_vector = 0x88fb20
gcpro1 = {
next = 0xa6f730,
var = 0x20,
nvars = 0
}
gcpro2 = {
next = 0x0,
var = 0x0,
nvars = 0
}
gcpro3 = {
next = 0x88fbe0,
var = 0xa6f730,
nvars = 8977316
}
i = 0
tem = 8977320
#18 0x01021f4f in Feval (form=46397854) at eval.c:2455
fun = 19092965
val = -2089560314
original_fun = 47396370
original_args = 46147610
funcar = 0
backtrace = {
next = 0x0,
function = 0x88fc84,
args = 0x88fb20,
nargs = 0,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
gcpro1 = {
next = 0x88fd18,
var = 0x0,
nvars = 33689212
}
gcpro2 = {
next = 0x88fd18,
var = 0x88fd1c,
nvars = 0
}
gcpro3 = {
next = 0x0,
var = 0x1,
nvars = 1
}
#19 0x0100607e in top_level_2 () at keyboard.c:1365
No locals.
#20 0x0102065c in internal_condition_case (bfun=0x100606b <top_level_2>,
handlers=46205170, hfun=0x1005ce6 <cmd_error>) at eval.c:1509
val = 0
c = {
tag = 46147610,
val = 46147610,
next = 0x88fdb0,
gcpro = 0x0,
jmp = {8977784, 2130567168, 0, 0, 8977580, 16909812, 8978372, 0,
16843008, 8977904, 1977456257, 8977728, 1983197756, 1983197840,
-1, 1977456423},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 0,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 46205170,
var = 46147610,
chosen_clause = 10919024,
tag = 0x88fcf0,
next = 0x0
}
#21 0x010060b0 in top_level_1 () at keyboard.c:1373
No locals.
#22 0x0102014d in internal_catch (tag=46203338, func=0x1006080 <top_level_1>,
arg=46147610) at eval.c:1245
c = {
tag = 46203338,
val = 46147610,
next = 0x0,
gcpro = 0x0,
jmp = {8977960, 2130567168, 0, 0, 8977820, 16908606, 8978372, 0,
20846784, 46147610, 46186496, 16882645, 20846784, 3, 1983185040,
8978008},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 0,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#23 0x01005ff2 in command_loop () at keyboard.c:1328
No locals.
#24 0x01005902 in recursive_edit_1 () at keyboard.c:950
count = 1
val = -2089090643
#25 0x01005a66 in Frecursive_edit () at keyboard.c:1012
count = 0
buffer = 46147610
#26 0x0100282d in main (argc=4, argv=0xd111e0) at emacs.c:1782
dummy = 2130567168
stack_bottom_variable = 126 '~'
do_initial_setlocale = 1
skip_args = 0
no_loadup = 0
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x11f07f0 "U\211\345\203\354\b\241\214\207\071\001\213"
Lisp Backtrace:
"w32-shell-execute" (0x88f390)
"eval" (0x88f4e4)
"command-line-1" (0x88f734)
"command-line" (0x88f974)
"normal-top-level" (0x88fb20)
(gdb) q
A debugging session is active.
Inferior 1 [process 3848] will be killed.
Quit anyway? (y or n) error return ../../gdb-7.1/gdb/windows-nat.c:1162 was 5
--
Harbin Institute of Technology, China
Chunyu Wang
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file
2010-05-07 14:21 ` Chunyu Wang
@ 2010-05-07 15:12 ` Eli Zaretskii
2010-05-07 16:29 ` Chunyu Wang
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2010-05-07 15:12 UTC (permalink / raw)
To: Chunyu Wang; +Cc: 6126
> From: Chunyu Wang <cymacs@gmail.com>
> Date: Fri, 7 May 2010 22:21:39 +0800
> Cc: 6126@debbugs.gnu.org
>
> 2010/5/7 Eli Zaretskii <eliz@gnu.org>:
> > 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)?
> Crashed as before for an unoptimized build one. The following is my tracing and
> information about `tbl' and `val'. If need some other thing, just tell
> me how to get it.
Can you try the following patch, and see if it resolves the problem?
=== modified file 'src/w32fns.c'
--- src/w32fns.c 2010-03-31 09:08:40 +0000
+++ src/w32fns.c 2010-05-07 15:07:43 +0000
@@ -47,6 +47,7 @@ along with GNU Emacs. If not, see <http
#include "systime.h"
#include "termhooks.h"
#include "w32heap.h"
+#include "w32.h"
#include "bitmaps/gray.xbm"
@@ -6333,6 +6334,7 @@ an integer representing a ShowWindow fla
Lisp_Object operation, document, parameters, show_flag;
{
Lisp_Object current_dir;
+ char *errstr;
CHECK_STRING (document);
@@ -6353,7 +6355,17 @@ an integer representing a ShowWindow fla
XINT (show_flag) : SW_SHOWDEFAULT))
> 32)
return Qt;
- error ("ShellExecute failed: %s", w32_strerror (0));
+ errstr = w32_strerror (0);
+ /* The error string might be encoded in the locale's encoding. */
+ if (!NILP (Vlocale_coding_system))
+ {
+ Lisp_Object decoded =
+ code_convert_string_norecord (make_unibyte_string (errstr,
+ strlen (errstr)),
+ Vlocale_coding_system, 0);
+ errstr = (char *)SDATA (decoded);
+ }
+ error ("ShellExecute failed: %s", errstr);
}
/* Lookup virtual keycode from string representing the name of a
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file
2010-05-07 15:12 ` Eli Zaretskii
@ 2010-05-07 16:29 ` Chunyu Wang
2010-05-07 17:16 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Chunyu Wang @ 2010-05-07 16:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 6126
2010/5/7 Eli Zaretskii <eliz@gnu.org>:
> Can you try the following patch, and see if it resolves the problem?
Yes, it works properly, and the better thing is error message in Chinese.
Thanks.
--
Harbin Institute of Technology, China
Chunyu Wang
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file
2010-05-07 16:29 ` Chunyu Wang
@ 2010-05-07 17:16 ` Eli Zaretskii
2010-05-07 20:52 ` Lennart Borgman
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2010-05-07 17:16 UTC (permalink / raw)
To: Chunyu Wang; +Cc: 6126-done
> From: Chunyu Wang <cymacs@gmail.com>
> Date: Sat, 8 May 2010 00:29:39 +0800
> Cc: 6126@debbugs.gnu.org
>
> 2010/5/7 Eli Zaretskii <eliz@gnu.org>:
> > Can you try the following patch, and see if it resolves the problem?
>
> Yes, it works properly, and the better thing is error message in Chinese.
> Thanks.
Thanks for testing. I now installed this change in the repository.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file
2010-05-07 17:16 ` Eli Zaretskii
@ 2010-05-07 20:52 ` Lennart Borgman
2010-05-08 7:15 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Lennart Borgman @ 2010-05-07 20:52 UTC (permalink / raw)
To: Eli Zaretskii, 6126; +Cc: 6126-done, Chunyu Wang
On Fri, May 7, 2010 at 7:16 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Chunyu Wang <cymacs@gmail.com>
>> Date: Sat, 8 May 2010 00:29:39 +0800
>> Cc: 6126@debbugs.gnu.org
>>
>> 2010/5/7 Eli Zaretskii <eliz@gnu.org>:
>> > Can you try the following patch, and see if it resolves the problem?
>>
>> Yes, it works properly, and the better thing is error message in Chinese.
>> Thanks.
>
> Thanks for testing. I now installed this change in the repository.
In what branch?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file
2010-05-07 20:52 ` Lennart Borgman
@ 2010-05-08 7:15 ` Eli Zaretskii
0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2010-05-08 7:15 UTC (permalink / raw)
To: Lennart Borgman; +Cc: 6126, cymacs
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Fri, 7 May 2010 22:52:33 +0200
> Cc: Chunyu Wang <cymacs@gmail.com>, 6126-done@debbugs.gnu.org
>
> On Fri, May 7, 2010 at 7:16 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Chunyu Wang <cymacs@gmail.com>
> >> Date: Sat, 8 May 2010 00:29:39 +0800
> >> Cc: 6126@debbugs.gnu.org
> >>
> >> 2010/5/7 Eli Zaretskii <eliz@gnu.org>:
> >> > Can you try the following patch, and see if it resolves the problem?
> >>
> >> Yes, it works properly, and the better thing is error message in Chinese.
> >> Thanks.
> >
> > Thanks for testing. I now installed this change in the repository.
>
> In what branch?
Trunk, of course.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2010-05-08 7:15 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-06 16:08 bug#6126: 24.0.50; Segmentation fault when w32-shell-execute try to open an unassociated file Chunyu Wang
2010-05-07 0:00 ` Lennart Borgman
2010-05-07 1:52 ` Chunyu Wang
2010-05-07 9:27 ` Eli Zaretskii
2010-05-07 10:52 ` Lennart Borgman
2010-05-07 9:03 ` Eli Zaretskii
2010-05-07 12:17 ` Chunyu Wang
2010-05-07 14:21 ` Chunyu Wang
2010-05-07 15:12 ` Eli Zaretskii
2010-05-07 16:29 ` Chunyu Wang
2010-05-07 17:16 ` Eli Zaretskii
2010-05-07 20:52 ` Lennart Borgman
2010-05-08 7:15 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).