unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* 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).