On Tuesday, August 28, 2012 7:08:51 AM UTC+4, Sean Estabrooks wrote:
> This removes the need for older code that avoided a crash
> 
> but meant that output wasn't displayed.

Hi, Sean!

Looks like it breaks with my configuration (Fedora 12 x86_64, gcc 4.4.5). When 
I try to "print", vim receives SIGSEGV:

:py print(dir())
['__builtins__', '__doc__', '__name__', '__package__', 'sys']
<lots of weird stuff from memory>
-- More --
Program received signal SIGSEGV, Segmentation fault.
0x0000003599c81cf2 in memchr () from /lib64/libc.so.6
(gdb) bt
#0  0x0000003599c81cf2 in memchr () from /lib64/libc.so.6
#1  0x00000000005ba6e3 in writer (fn=0x4bebbc <msg>, str=0xac3035 "", 
n=219043237432) at if_py_both.h:178
#2  0x00000000005ba2e3 in OutputWrite (self=0x84f820, args=0x7ffff13fa6d0) at 
if_py_both.h:86
#3  0x000000336e643db3 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0
#4  0x000000336e6d7ba3 in PyEval_CallObjectWithKeywords () from 
/usr/lib64/libpython2.6.so.1.0
#5  0x000000336e667304 in PyFile_WriteObject () from 
/usr/lib64/libpython2.6.so.1.0
#6  0x000000336e6dbf7b in PyEval_EvalFrameEx () from 
/usr/lib64/libpython2.6.so.1.0
#7  0x000000336e6df4e9 in PyEval_EvalCodeEx () from 
/usr/lib64/libpython2.6.so.1.0
#8  0x000000336e6df5b2 in PyEval_EvalCode () from /usr/lib64/libpython2.6.so.1.0
#9  0x000000336e6fa52c in ?? () from /usr/lib64/libpython2.6.so.1.0
#10 0x000000336e6fa73a in PyRun_StringFlags () from 
/usr/lib64/libpython2.6.so.1.0
#11 0x000000336e6fb890 in PyRun_SimpleStringFlags () from 
/usr/lib64/libpython2.6.so.1.0
#12 0x00000000005bf548 in DoPythonCommand (eap=0x7fffffffd5f0, cmd=0x8953b3 
"print(dir())", rettv=0x0) at if_python.c:827
#13 0x00000000005bf689 in ex_python (eap=0x7fffffffd5f0) at if_python.c:879
#14 0x000000000046afc8 in do_one_cmd (cmdlinep=0x7fffffffdc68, sourcing=0, 
cstack=0x7fffffffd7c0, fgetline=0x48077e <getexline>, cookie=0x0) at 
ex_docmd.c:2677
#15 0x0000000000468656 in do_cmdline (cmdline=0x0, fgetline=0x48077e 
<getexline>, cookie=0x0, flags=0) at ex_docmd.c:1122
#16 0x00000000004f0c63 in nv_colon (cap=0x7fffffffdd90) at normal.c:5412
#17 0x00000000004e985d in normal_cmd (oap=0x7fffffffde50, toplevel=1) at 
normal.c:1193
#18 0x00000000005cfff1 in main_loop (cmdwin=0, noexmode=0) at main.c:1294
#19 0x00000000005cfabe in main (argc=1, argv=0x7fffffffe168) at main.c:998
(gdb) fr 2
#2  0x00000000005ba2e3 in OutputWrite (self=0x84f820, args=0x7ffff13fa6d0) at 
if_py_both.h:86
86      writer((writefn)(error ? emsg : msg), (char_u *)str, len);
(gdb) p len 
$1 = 219043332157

This reproduces both in optimized and unoptimized builds. 

I tried this patch

diff --git a/src/if_py_both.h b/src/if_py_both.h
--- a/src/if_py_both.h
+++ b/src/if_py_both.h
@@ -74,7 +74,7 @@
     static PyObject *
 OutputWrite(PyObject *self, PyObject *args)
 {
-    Py_ssize_t len;
+    Py_ssize_t len = 0;
     char *str = NULL;
     int error = ((OutputObject *)(self))->error;

and it helped, but I couldn't find where Python c-api states that 
PyArg_ParseTuple doesn't set `len' in some cases.

-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Raspunde prin e-mail lui