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