我给Vim的Python3支持打了个补丁，发到邮件列表上只有Bram表示希望有人来测试就没有下方了。于是，这么久了，这个补丁的内存泄漏问题一直未被发现，直到看到蓝色基因的这篇文章。花了一个下午，发现我原来的补丁不仅没有修正本来就有的内存泄漏，反而雪上加霜，浪费了更多的内存。现在终于弄好了，放在我的陈列室里了，同时还莫名其妙地修正了另一个小问题。
既然是内存泄漏，我首先想到的是valgrind这个工具。于是跑了一下：
valgrind --leak-check=full --show-reachable=yes vim
在开启的 Vim 中我 source 了蓝色基因的测试脚本：
lcd %:h
tabedit tmpbuffer
setlocal buftype=nofile
python3 << EOF
for i in range(3):
flines= ['x'*200] * 50000
vim.command("%s+\\_.*++g")
for fl in flines:
vim.current.buffer.append(fl)
del flines[:]
EOF
整个过程CPU占到100%，而且运行速度极慢，内存消耗也非常多。最后Vim终于按我的指令退出时，valgrind刷屏了大约十几秒钟！而其间我看到除了Python的字样外，还有不少rb的字样。难道Ruby支持也有类似的问题？不过我不管它。重新编译了个只有--enable-python3interp选项的 Vim，这回跑起来快了一些，也没有那么多不相干的内存泄漏了。我也学聪明了点，把信息重定向到文件：
valgrind --leak-check=full --show-reachable=yes src/vim 2> log
这样可以方便地在log中找“if_py”字符串了。可惜我弄的时候没想到自己会来写博客，所以log文件并没有保存。。。
首先我找到了DoPy3Command这个函数，valgrind说它里面分配的内存没有被释放。这里边的PyUnicode_AsEncodedString这块是我加的：
/* PyRun_SimpleString expects a UTF-8 string. Wrong encoding may cause
* SyntaxError (unicode error). */
cmdstr = PyUnicode_Decode(cmd, strlen(cmd), p_enc, NULL);
PyRun_SimpleString(PyBytes_AsString(PyUnicode_AsEncodedString(cmdstr, "utf-8", NULL)));
然后我能怎么办呢？当然是查Python的文档了。于是注意到文档上说PyUnicode_AsEncodedString返回的是新的引用。又去看官方教程上的示例，才知道如果一个API返回了新的引用，那么用完后应当手动Py_XDECREF！就像是strdup函数，它内部帮你malloc了，你自己用完后要记着free掉。（Py_XDECREF和Py_DECREF的差别是，前者可以传NULL。）
于是就改吧，所有通过PyUnicode_AsEncodedString得到的对象都要Py_XDECREF下。为此，不仅需要临时变量来存储这个对象，更让我郁闷的是，在两个Python版本共有的函数StringToLine中有这样一段代码：
str = PyString_AsString(bytes);
len = PyString_Size(bytes);
这里的两个函数/宏我之前是这样定义的：
#define _PyUnicode_AsBytes(obj) PyUnicode_AsEncodedString(obj, p_enc, NULL) #define PyString_AsString(obj) PyBytes_AsString(_PyUnicode_AsBytes(obj)) #define PyString_Size(obj) PyBytes_GET_SIZE(_PyUnicode_AsBytes(obj))
这下我没辙了，只好又改了if_py_both.h和if_python.c文件，加了两个宏：PyString_AsBytes和PyString_FreeBytes。它们在 Python2 的代码中什么也不做，但是在 Python3 的代码中用来保存和释放中间对象：
#define PyString_AsBytes(obj) PyUnicode_AsEncodedString(obj, p_enc, NULL); #define PyString_FreeBytes(obj) Py_XDECREF(bytes) #define PyString_AsString(obj) PyBytes_AsString(obj) #define PyString_Size(obj) PyBytes_GET_SIZE(bytes)
有人说，if it ain't broken, don't fix it。可是，虽然问题只出在 Python3 部分，我还是得改 Python2 部分，感觉很不爽。
这样改完，再次反复运行测试代码，结果不遂人愿，依旧泄漏了不少内存。于是继续valgrind，又找到这里：
static void
BufferDestructor(PyObject *self)
{
BufferObject *this = (BufferObject *)(self);
if (this->buf && this->buf != INVALID_BUFFER_VALUE)
this->buf->b_python3_ref = NULL;
}
然后再次查教程中的示例：
static void
Noddy_dealloc(Noddy* self)
{
Py_XDECREF(self->first);
Py_XDECREF(self->last);
Py_TYPE(self)->tp_free((PyObject*)self);
}
再看看 Python2 部分的代码，在相应的函数里有Py_DECREF，于是把这示例的最后一行给BufferDestructor以及WindowDestructor和RangeDestructor加上。再测试，内存不再消耗100多M了，反复source也不会继续增加，于是作出结论：Vim 的 Python3 支持部分没有已知的 bug 了！
做完这一切，我只想说：Vim 这 Python3 支持也太 broken 了吧，中文经常乱码就算了，vim.error不能用我也忍了，竟然还内存泄漏！难道写这个代码的人也是初学Python C API啊？
不过抱怨归抱怨，还是很感谢原作者的，不然我连修正都不可能。不过，patch 弄好也提交了，却一直没人理我，原作者难道是一时兴起才写的、然后就消失了？
最后，补丁现在放到陈列室了。
火狐4新增的标签页分组功能很好用，可以把与当前工作不相关的网页放到另外的组，以免像Chrome那样让标签页挤满标签栏，所以
