Python的内存泄漏及gc模块的使用
                  -- 6.11日错误修正版

             Horin|贺勤
        Email: horin153@msn.com
        Blog: http://blog.csdn.net/horin153/

    在 Python 中，为了解决内存泄漏问题，采用了对象引用计数，并基于引用计数实现自动垃圾回收。
    因为 Python 有了自动垃圾回收功能，不少初学者就认为自己从此过上了好日子，不必再受内存泄漏的骚扰了。但如果查看一下 Python 文档对 __del__() 函数的描述，就知道好日子里也是有阴云的。下面摘抄一点文档内容：
    Some common situations that may prevent the reference count of an object from going to zero include: circular references between objects (e.g., a doubly-linked list or a tree data structure with parent and child pointers); a reference to the object on the stack frame of a function that caught an exception (the traceback stored in sys.exc_traceback keeps the stack frame alive); or a reference to the object on the stack frame that raised an unhandled exception in interactive mode (the traceback stored in sys.last_traceback keeps the stack frame alive).
    可见，有 __del__() 函数的对象间的循环引用是导致内存泄漏的主凶。特别说明：对没有 __del__() 函数的 Python 对象间的循环引用，是可以被自动垃圾回收掉的。

    如何知道一个对象是否内存泄漏了呢？
    方法一、当你认为一个对象应该被销毁时（即引用计数为 0），可以通过 sys.getrefcount(obj) 来获取对象的引用计数，并根据返回值是否为 0 来判断是否内存泄漏。如果返回的引用计数不为 0，说明在此刻对象 obj 是不能被垃圾回收器回收掉的。
    方法二、也可以通过 Python 扩展模块 gc 来查看不能回收的对象的详细信息。


    首先，来看一段正常的测试代码：

#--------------- code begin --------------

# -*- coding: utf-8 -*-

import gc
import sys

class CGcLeak(object):
    def __init__(self):
        self._text = '#'*10

    def __del__(self):
        pass

def make_circle_ref():
    _gcleak = CGcLeak()
#   _gcleak._self = _gcleak # test_code_1
    print '_gcleak ref count0:%d' % sys.getrefcount(_gcleak)
    del _gcleak
    try:
        print '_gcleak ref count1:%d' % sys.getrefcount(_gcleak)
    except UnboundLocalError:
        print '_gcleak is invalid!'

def test_gcleak():
    # Enable automatic garbage collection.
    gc.enable()
    # Set the garbage collection debugging flags.
    gc.set_debug(gc.DEBUG_COLLECTABLE | gc.DEBUG_UNCOLLECTABLE | \
        gc.DEBUG_INSTANCES | gc.DEBUG_OBJECTS)

    print 'begin leak test...'
    make_circle_ref()

    print 'begin collect...'
    _unreachable = gc.collect()
    print 'unreachable object num:%d' % _unreachable
    print 'garbage object num:%d' % len(gc.garbage)

if __name__ == '__main__':
    test_gcleak()

#--------------- code end ----------------

    在 test_gcleak() 中，设置垃圾回收器调试标志后，再用 collect() 进行垃圾回收，最后打印出该次垃圾回收发现的不可达的垃圾对象数和整个解释器中的垃圾对象数。

    gc.garbage 是一个 list 对象，列表项是垃圾收集器发现的不可达（即是垃圾对象）、但又不能释放（即不能回收）的对象。文档描述为：A list of objects which the collector found to be unreachable but could not be freed (uncollectable objects).
    通常，gc.garbage 中的对象是引用环中的对象。因为 Python 不知道按照什么样的安全次序来调用环中对象的 __del__() 函数，导致对象始终存活在 gc.garbage 中，造成内存泄漏。如果知道一个安全的次序，那么就打破引用环，再执行 del gc.garbage[:] ，以清空垃圾对象列表。

    上段代码输出为（#后字符串为笔者所加注释）：
#-----------------------------------------
begin leak test...
# 变量 _gcleak 的引用计数为 2.
_gcleak ref count0:2
# _gcleak 变为不可达(unreachable)的非法变量.
_gcleak is invalid!
# 开始垃圾回收
begin collect...
# 本次垃圾回收发现的不可达的垃圾对象数为 0.
unreachable object num:0
# 整个解释器中的垃圾对象数为 0.
garbage object num:0
#-----------------------------------------
    可见 _gcleak 对象的引用计数是正确的，也没有任何对象发生内存泄漏。

    如果不注释掉 make_circle_ref() 中的 test_code_1 语句：
    _gcleak._self = _gcleak
也就是让 _gcleak 形成一个自己对自己的循环引用。再运行上述代码，输出结果就变成：
#-----------------------------------------
begin leak test...
_gcleak ref count0:3
_gcleak is invalid!
begin collect...
# 发现可以回收的垃圾对象: 地址为 012AA090，类型为 CGcLeak.
gc: uncollectable <CGcLeak 012AA090>
gc: uncollectable <dict 012AC1E0>
unreachable object num:2
#!! 不能回收的垃圾对象数为 1，导致内存泄漏！
garbage object num:1
#-----------------------------------------
    可见 <CGcLeak 012AA090> 对象发生了内存泄漏！！而多出的 dict 垃圾就是泄漏的 _gcleak 对象的字典，打印出字典信息为:
{'_self': <__main__.CGcLeak object at 0x012AA090>, '_text': '##########'}

    除了对自己的循环引用，多个对象间的循环引用也会导致内存泄漏。简单举例如下：

#--------------- code begin --------------

class CGcLeakA(object):
    def __init__(self):
        self._text = '#'*10

    def __del__(self):
        pass

class CGcLeakB(object):
    def __init__(self):
        self._text = '*'*10

    def __del__(self):
        pass

def make_circle_ref():
    _a = CGcLeakA()
    _b = CGcLeakB()
    _a._b = _b  # test_code_2
    _b._a = _a  # test_code_3
    print 'ref count0:a=%d b=%d' % \
        (sys.getrefcount(_a), sys.getrefcount(_b))
#   _b._a = None    # test_code_4
    del _a
    del _b
    try:
        print 'ref count1:a=%d' % sys.getrefcount(_a)
    except UnboundLocalError:
        print '_a is invalid!'
    try:
        print 'ref count2:b=%d' % sys.getrefcount(_b)
    except UnboundLocalError:
        print '_b is invalid!'

#--------------- code end ----------------

    这次测试后输出结果为：
#-----------------------------------------
begin leak test...
ref count0:a=3 b=3
_a is invalid!
_b is invalid!
begin collect...
gc: uncollectable <CGcLeakA 012AA110>
gc: uncollectable <CGcLeakB 012AA0B0>
gc: uncollectable <dict 012AC1E0>
gc: uncollectable <dict 012AC0C0>
unreachable object num:4
garbage object num:2
#-----------------------------------------
可见 _a,_b 对象都发生了内存泄漏。因为二者是循环引用，垃圾回收器不知道该如何回收，也就是不知道该首先调用那个对象的 __del__() 函数。

    采用以下任一方法，打破环状引用，就可以避免内存泄漏：
[1] 注释掉 make_circle_ref() 中的 test_code_2 语句；
[2] 注释掉 make_circle_ref() 中的 test_code_3 语句；
[3] 取消对 make_circle_ref() 中的 test_code_4 语句的注释。
相应输出结果变为：
#-----------------------------------------
begin leak test...
ref count0:a=2 b=3  # 注：此处输出结果视情况变化.
_a is invalid!
_b is invalid!
begin collect...
unreachable object num:0
garbage object num:0
#-----------------------------------------


    结论：Python 的 gc 有比较强的功能，比如设置 gc.set_debug(gc.DEBUG_LEAK) 就可以进行循环引用导致的内存泄露的检查。如果在开发时进行内存泄露检查；在发布时能够确保不会内存泄露，那么就可以延长 Python 的垃圾回收时间间隔、甚至主动关闭垃圾回收机制，从而提高运行效率。


推荐阅读文献

1, Python垃圾回收算法描述,http://wiki.woodpecker.org.cn/moin/python_ref_circle_gc
2, Garbage Collection for Python,http://arctrix.com/nas/python/gc/

• Windows7在微软WinHEC 2008上揭开神秘面纱
• 搜狐网站诚聘Java、PHP和C++工程师

内容：

编译
运行 gdb
调试会话示例
使用断点
更多断点和观察点
Core 文件
堆栈跟踪
连接到其它进程
其它小技巧
结束语
参考资料
关于作者

GNU 调试器简介
作者:David Seager


Linux 的大部分特色源自于 shell 的 GNU 调试器，也称作 gdb。gdb 可以让您查看程序的内部结构、打印变量值、设置断点，以及单步调试源代码。它是功能极其强大的工具，适用于修复程序代码中的问题。在本文中，我将尝试说明 gdb 有多棒，多实用。

编译
开始调试之前，必须用程序中的调试信息编译要调试的程序。这样，gdb 才能够调试所使用的变量、代码行和函数。如果要进行编译，请在 gcc（或 g++）下使用额外的 '-g' 选项来编译程序：

gcc -g eg.c -o eg

运行 gdb
在 shell 中，可以使用 'gdb' 命令并指定程序名作为参数来运行 gdb，例如 'gdb eg'；或者在 gdb 中，可以使用 file 命令来装入要调试的程序，例如 'file eg'。这两种方式都假设您是在包含程序的目录中执行命令。装入程序之后，可以用 gdb 命令 'run' 来启动程序。

调试会话示例
如果一切正常，程序将执行到结束，此时 gdb 将重新获得控制。但如果有错误将会怎么样？这种情况下，gdb 会获得控制并中断程序，从而可以让您检查所有事物的状态，如果运气好的话，可以找出原因。为了引发这种情况，我们将使用一个示例程序：

代码示例 eg1.c
#include

int wib(int no1, int no2)
{
int result, diff;
diff = no1 - no2;
result = no1 / diff;
return result;
}

int main(int argc, char *argv[])
{
int value, div, result, i, total;

value = 10;
div = 6;
total = 0;

for(i = 0; i < 10; i++)
{
result = wib(value, div);
total += result;
div++;
value--;
}

printf("%d wibed by %d equals %dn", value, div, total);
return 0;
}




这个程序将运行 10 次 for 循环，使用 'wib()' 函数计算出累积值，最后打印出结果。

在您喜欢的文本编辑器中输入这个程序（要保持相同的行距），保存为 'eg1.c'，使用 'gcc -g eg1.c -o eg1' 进行编译，并用 'gdb eg1' 启动 gdb。使用 'run' 运行程序可能会产生以下消息：


Program received signal SIGFPE, Arithmetic exception.
0x80483ea in wib (no1=8, no2=8) at eg1.c:7
7 result = no1 / diff;
(gdb)



gdb 指出在程序第 7 行发生一个算术异常，通常它会打印这一行以及 wib() 函数的自变量值。要查看第 7 行前后的源代码，请使用 'list' 命令，它通常会打印 10 行。再次输入 'list'（或者按回车重复上一条命令）将列出程序的下 10 行。从 gdb 消息中可以看出，第 7 行中的除法运算出了错，程序在这一行中将变量 "no1" 除以 "diff"。

要查看变量的值，使用 gdb 'print' 命令并指定变量名。输入 'print no1' 和 'print diff'，可以相应看到 "no1" 和 "diff" 的值，结果如下：


(gdb) print no1
$5 = 8
(gdb) print diff
$2 = 0



gdb 指出 "no1" 等于 8，"diff" 等于 0。根据这些值和第 7 行中的语句，我们可以推断出算术异常是由除数为 0 的除法运算造成的。清单显示了第 6 行计算的变量 "diff"，我们可以打印 "diff" 表达式（使用 'print no1 - no2' 命令），来重新估计这个变量。gdb 告诉我们 wib 函数的这两个自变量都等于 8，于是我们要检查调用 wib() 函数的 main() 函数，以查看这是在什么时候发生的。在允许程序自然终止的同时，我们使用 'continue' 命令告诉 gdb 继续执行。


(gdb) continue
Continuing.

Program terminated with signal SIGFPE, Arithmetic exception.
The program no longer exists.



使用断点
为了查看在 main() 中发生了什么情况，可以在程序代码中的某一特定行或函数中设置断点，这样 gdb 会在遇到断点时中断执行。可以使用命令 'break main' 在进入 main() 函数时设置断点，或者可以指定其它任何感兴趣的函数名来设置断点。然而，我们只希望在调用 wib() 函数之前中断执行。输入 'list main' 将打印从 main() 函数开始的源码清单，再次按回车将显示第 21 行上的 wib() 函数调用。要在那一行上设置断点，只需输入 'break 21'。gdb 将发出以下响应：


(gdb) break 21
Breakpoint 1 at 0x8048428: file eg1.c, line 21.



以显示它已在我们请求的行上设置了 1 号断点。'run' 命令将从头重新运行程序，直到 gdb 中断为止。发生这种情况时，gdb 会生成一条消息，指出它在哪个断点上中断，以及程序运行到何处：


Breakpoint 1, main (argc=1, argv=0xbffff954) at eg1.c:21
21 result = wib(value, div);



发出 'print value' 和 'print div' 将会显示在第一次调用 wib() 时，变量分别等于 10 和 6，而 'print i' 将会显示 0。幸好，gdb 将显示所有局部变量的值，并使用 'info locals' 命令保存大量输入信息。

从以上的调查中可以看出，当 "value" 和 "div" 相等时就会出现问题，因此输入 'continue' 继续执行，直到下一次遇到 1 号断点。对于这次迭代，'info locals' 显示了 value=9 和 div=7。

与其再次继续，还不如使用 'next' 命令单步调试程序，以查看 "value" 和 "div" 是如何改变的。gdb 将响应：


(gdb) next
22 total += result;



再按两次回车将显示加法和减法表达式：


(gdb)
23 div++;
(gdb)
24 value--;



再按两次回车将显示第 21 行，wib() 调用。'info locals' 将显示目前 "div" 等于 "value"，这就意味着将发生问题。如果有兴趣，可以使用 'step' 命令（与 'next' 形成对比，'next' 将跳过函数调用）来继续执行 wib() 函数，以再次查看除法错误，然后使用 'next' 来计算 "result"。

现在已完成了调试，可以使用 'quit' 命令退出 gdb。由于程序仍在运行，这个操作会终止它，gdb 将提示您确认。

更多断点和观察点
由于我们想要知道在调用 wib() 函数之前 "value" 什么时候等于 "div"，因此在上一示例中我们在第 21 行中设置断点。我们必须继续执行两次程序才会发生这种情况，但是只要在断点上设置一个条件就可以使 gdb 只在 "value" 与 "div" 真正相等时暂停。要设置条件，可以在定义断点时指定 "break if "。将 eg1 再次装入 gdb，并输入：


(gdb) break 21 if value==div
Breakpoint 1 at 0x8048428: file eg1.c, line 21.



如果已经在第 21 行中设置了断点，如 1 号断点，则可以使用 'condition' 命令来代替在断点上设置条件：


(gdb) condition 1 value==div



使用 'run' 运行 eg1.c 时，如果 "value" 等于 "div"，gdb 将中断，从而避免了在它们相等之前必须手工执行 'continue'。调试 C 程序时，断点条件可以是任何有效的 C 表达式，一定要是程序所使用语言的任意有效表达式。条件中指定的变量必须在设置了断点的行中，否则表达式就没有什么意义！

使用 'condition' 命令时，如果指定断点编号但又不指定表达式，可以将断点设置成无条件断点，例如，'condition 1' 就将 1 号断点设置成无条件断点。

要查看当前定义了什么断点及其条件，请发出命令 'info break'：


(gdb) info break
Num Type Disp Enb Address What
1 breakpoint keep y 0x08048428 in main at eg1.c:21
stop only if value == div
breakpoint already hit 1 time



除了所有条件和已经遇到断点多少次之外，断点信息还在 'Enb' 列中指定了是否启用该断点。可以使用命令 'disable '、'enable ' 或 'delete ' 来禁用、启用和彻底删除断点，例如 'disable 1' 将阻止在 1 号断点处中断。

如果我们对 "value" 什么时候变得与 "div" 相等更感兴趣，那么可以使用另一种断点，称作监视。当指定表达式的值改变时，监视点将中断程序执行，但必须在表达式中所使用的变量在作用域中时设置监视点。要获取作用域中的 "value" 和 "div"，可以在 main 函数上设置断点，然后运行程序，当遇到 main() 断点时设置监视点。重新启动 gdb，并装入 eg1，然后输入：


(gdb) break main
Breakpoint 1 at 0x8048402: file eg1.c, line 15.
(gdb) run
...
Breakpoint 1, main (argc=1, argv=0xbffff954) at eg1.c:15
15 value = 10;



要了解 "div" 何时更改，可以使用 'watch div'，但由于要在 "div" 等于 "value" 时中断，那么应输入：


(gdb) watch div==value
Hardware watchpoint 2: div == value



如果继续执行，那么当表达式 "div==value" 的值从 0（假）变成 1（真）时，gdb 将中断：


(gdb) continue
Continuing.
Hardware watchpoint 2: div == value

Old value = 0
New value = 1
main (argc=1, argv=0xbffff954) at eg1.c:19
19 for(i = 0; i < 10; i++)



'info locals' 命令将验证 "value" 是否确实等于 "div"（再次声明，是 8）。

'info watch' 命令将列出已定义的监视点和断点（此命令等价于 'info break'），而且可以使用与断点相同的语法来启用、禁用和删除监视点。

core 文件
在 gdb 下运行程序可以使俘获错误变得更容易，但在调试器外运行的程序通常会中止而只留下一个 core 文件。gdb 可以装入 core 文件，并让您检查程序中止之前的状态。

在 gdb 外运行示例程序 eg1 将会导致核心信息转储：

$ ./eg1
Floating point exception (core dumped)



要使用 core 文件启动 gdb，在 shell 中发出命令 'gdb eg1 core' 或 'gdb eg1 -c core'。gdb 将装入 core 文件，eg1 的程序清单，显示程序是如何终止的，并显示非常类似于我们刚才在 gdb 下运行程序时看到的消息：


...
Core was generated by `./eg1'.
Program terminated with signal 8, Floating point exception.
...
#0 0x80483ea in wib (no1=8, no2=8) at eg1.c:7
7 result = no1 / diff;



此时，可以发出 'info locals'、'print'、'info args' 和 'list' 命令来查看引起除数为零的值。'info variables' 命令将打印出所有程序变量的值，但这要进行很长时间，因为 gdb 将打印 C 库和程序代码中的变量。为了更容易地查明在调用 wib() 的函数中发生了什么情况，可以使用 gdb 的堆栈命令。

堆栈跟踪
程序“调用堆栈”是当前函数之前的所有已调用函数的列表（包括当前函数）。每个函数及其变量都被分配了一个“帧”，最近调用的函数在 0 号帧中（“底部”帧）。要打印堆栈，发出命令 'bt'（'backtrace' [回溯] 的缩写）：


(gdb) bt
#0 0x80483ea in wib (no1=8, no2=8) at eg1.c:7
#1 0x8048435 in main (argc=1, argv=0xbffff9c4) at eg1.c:21



此结果显示了在 main() 的第 21 行中调用了函数 wib()（只要使用 'list 21' 就能证实这一点），而且 wib() 在 0 号帧中，main() 在 1 号帧中。由于 wib() 在 0 号帧中，那么它就是执行程序时发生算术错误的函数。

实际上，发出 'info locals' 命令时，gdb 会打印出当前帧中的局部变量，缺省情况下，这个帧中的函数就是被中断的函数（0 号帧）。可以使用命令 'frame' 打印当前帧。要查看 main 函数（在 1 号帧中）中的变量，可以发出 'frame 1' 切换到 1 号帧，然后发出 'info locals' 命令：


(gdb) frame 1
#1 0x8048435 in main (argc=1, argv=0xbffff9c4) at eg1.c:21
21 result = wib(value, div);
(gdb) info locals
value = 8
div = 8
result = 4
i = 2
total = 6



此信息显示了在第三次执行 "for" 循环时（i 等于 2）发生了错误，此时 "value" 等于 "div"。

可以通过如上所示在 'frame' 命令中明确指定号码，或者使用 'up' 命令在堆栈中上移以及 'down' 命令在堆栈中下移来切换帧。要获取有关帧的进一步信息，如它的地址和程序语言，可以使用命令 'info frame'。

gdb 堆栈命令可以在程序执行期间使用，也可以在 core 文件中使用，因此对于复杂的程序，可以在程序运行时跟踪它是如何转到函数的。

连接到其它进程
除了调试 core 文件或程序之外，gdb 还可以连接到已经运行的进程（它的程序已经过编译，并加入了调试信息），并中断该进程。只需用希望 gdb 连接的进程标识替换 core 文件名就可以执行此操作。以下是一个执行循环并睡眠的示例程序：

eg2 示例代码
#include
int main(int argc, char *argv[])
{
int i;
for(i = 0; i < 60; i++)
{
sleep(1);
}

return 0;
}




使用 'gcc -g eg2.c -o eg2' 编译该程序并使用 './eg2 &' 运行该程序。请留意在启动该程序时在背景上打印的进程标识，在本例中是 1283：

./eg2 &
[3] 1283



启动 gdb 并指定进程标识，在我举的这个例子中是 'gdb eg2 1283'。gdb 会查找一个叫作 "1283" 的 core 文件。如果没有找到，那么只要进程 1283 正在运行（在本例中可能在 sleep() 中），gdb 就会连接并中断该进程：


...
/home/seager/gdb/1283: No such file or directory.
Attaching to program: /home/seager/gdb/eg2, Pid 1283
...
0x400a87f1 in __libc_nanosleep () from /lib/libc.so.6
(gdb)



此时，可以发出所有常用 gdb 命令。可以使用 'backtrace' 来查看当前位置与 main() 的相对关系，以及 mian() 的帧号是什么，然后切换到 main() 所在的帧，查看已经在 "for" 循环中运行了多少次：

(gdb) backtrace
#0 0x400a87f1 in __libc_nanosleep () from /lib/libc.so.6
#1 0x400a877d in __sleep (seconds=1) at ../sysdeps/unix/sysv/linux/sleep.c:78
#2 0x80483ef in main (argc=1, argv=0xbffff9c4) at eg2.c:7
(gdb) frame 2
#2 0x80483ef in main (argc=1, argv=0xbffff9c4) at eg2.c:7
7 sleep(1);
(gdb) print i
$1 = 50



如果已经完成了对程序的修改，可以 'detach' 命令继续执行程序，或者 'kill' 命令杀死进程。还可以首先使用 'file eg2' 装入文件，然后发出 'attach 1283' 命令连接到进程标识 1283 下的 eg2。

其它小技巧
gdb 可以让您通过使用 shell 命令在不退出调试环境的情况下运行 shell 命令，调用形式是 'shell [commandline]'，这有助于在调试时更改源代码。

最后，在程序运行时，可以使用 'set ' 命令修改变量的值。在 gdb 下再次运行 eg1，使用命令 'break 7 if diff==0' 在第 7 行（将在此处计算结果）设置条件断点，然后运行程序。当 gdb 中断执行时，可以将 "diff" 设置成非零值，使程序继续运行直至结束：


Breakpoint 1, wib (no1=8, no2=8) at eg1.c:7
7 result = no1 / diff;
(gdb) print diff
$1 = 0
(gdb) set diff=1
(gdb) continue
Continuing.
0 wibed by 16 equals 10

Program exited normally.



结束语
GNU 调试器是所有程序员工具库中的一个功能非常强大的工具。在本文中，我只介绍了 gdb 的一小部分功能。要了解更多知识，建议您阅读 GNU 调试器手册。

参考资料

GNU 调试器手册
调试会话示例的源代码。
连接示例的源代码。

关于作者

David Seager 是 IBM 的软件开发人员，他从事 Linux 和基于 Web 的应用工作已有两年时间了。

转自:IBM developerWorks中国网站

• Windows7在微软WinHEC 2008上揭开神秘面纱
• 搜狐网站诚聘Java、PHP和C++工程师

调试工具收集:

gdb ./run_name

backtrace:

查看调用函数

区别下strace.

strace是用来查看其他的运行情况.例如: strace make.

• Windows7在微软WinHEC 2008上揭开神秘面纱
• 搜狐网站诚聘Java、PHP和C++工程师

网络上有很多<浅谈C/C++内存泄漏及其检测工具>.

我:特别感兴趣的是:

一个工具:BoundsChecker

一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显示释放的内存。应用程序一般使用malloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用，我们就说这块内存泄漏了。以下这段小程序演示了堆内存发生泄漏的情形：

void MyFunction(int nSize)
{
　char* p= new char[nSize];
　if( !GetStringFrom( p, nSize ) ){
　　MessageBox(“Error”);
　　return;
　}
　…//using the string pointed by p;
　delete p;
} 

内存泄漏的发生方式：

　　以发生的方式来分类，内存泄漏可以分为4类：

　　1. 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。比如例二，如果Something()函数一直返回True，那么pOldBmp指向的HBITMAP对象总是发生泄漏。

　　2. 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。比如例二，如果Something()函数只有在特定环境下才返回True，那么pOldBmp指向的HBITMAP对象并不总是发生泄漏。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。

　　3. 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，但是因为这个类是一个Singleton，所以内存泄漏只会发生一次。另一个例子：

char* g_lpszFileName = NULL;

void SetFileName( const char* lpcszFileName )
{
　if( g_lpszFileName ){
　　free( g_lpszFileName );
　}
　g_lpszFileName = strdup( lpcszFileName );
} 

　　例三

　　如果程序在结束的时候没有释放g_lpszFileName指向的字符串，那么，即使多次调用SetFileName?()，总会有一块内存，而且仅有一块内存发生泄漏。

　　4. 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。举一个例子：

class Connection
{
　public:
　　Connection( SOCKET s);
　　~Connection();
　　…
　private:
　　SOCKET _socket;
　　…
};

class ConnectionManager
{
　public:
　　ConnectionManager(){}
　　~ConnectionManager(){
　　　list::iterator it;
　　　for( it = _connlist.begin(); it != _connlist.end(); ++it ){
　　　　delete （*it）;
　　　}
　　　_connlist.clear();
　　}
　　void OnClientConnected( SOCKET s ){
　　　Connection* p = new Connection(s);
　　　_connlist.push_back(p);
　　}
　　void OnClientDisconnected( Connection* pconn ){
　　　_connlist.remove( pconn );
　　　delete pconn;
　　}
　private:
　　list _connlist;
}; 

　　例四

　　假设在Client从Server端断开后，Server并没有呼叫OnClientDisconnected?()函数，那么代表那次连接的Connection对象就不会被及时的删除（在Server程序退出的时候，所有Connection对象会在ConnectionManager?的析构函数里被删除）。当不断的有连接建立、断开时隐式内存泄漏就发生了。

　　从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到。

• 搜狐网站诚聘Java、PHP和C++工程师
• Windows7在微软WinHEC 2008上揭开神秘面纱

http://blog.csdn.net/daijunhua/archive/2008/05/28/2489211.aspx

BoundsChecker 是一个Run-Time错误检测工具，它主要定位程序在运行时期发生的各种错误。BoundsChecker能检测的错误包括：

1))1、指针操作和内存、资源泄露错误，比如：

内存泄露；

资源泄露；

对指针变量的错误操作。

22、内存操作方面的错误，比如：

  内存读、写溢出；

  使用未初始化的内存。

33、API函数使用错误

BoundsChecker安装成功后，在你的VC++集成开发环境中，会多出了一个名为BoundsChecker的菜单，如下所示：

图3-1 BoundsChecker在VC++集成开发环境中添加的菜单

BoundsChecker 已经非常完好的集成到VC++集成开发环境中了。

使用BoundsChecker对程序的运行时错误进行检测，有两种使用模式可供选择。一种模式叫做ActiveCheck，一种模式叫做FinalCheck。下面分别进行介绍。

3.1 ActiveCheck

ActiveCheck是BoundsChecker提供的一种方便、快捷的错误检测模式，它能检测的错误种类有限，只包括：内存泄露错误、资源泄露错误、API函数使用错误。

要想使用ActiveCheck模式来检测程序的运行时错误，只需在VC++集成开发环境中打开BoundsChecker功能，然后从调试状态运行程序即可。此时ActiveCheck会在后台自动运行，随时检测程序是否发生了错误。下面说一下具体的使用步骤。

3．1．1 用ActiveCheck来检测错误

使用ActiveCheck的具体的操作步骤如下：

首先，在VC++集成开发环境中打开你要对其进行测试的程序，同时保证项目处于Debug编译状态下。

其次，确保VC++集成开发环境中[BoundsChecker/Integrated Debugging]菜单项和[BoundsChecker/Report Errors and Events]菜单项处于被选中的状态。只有这两项被选中，BoundsChecker才会在程序运行过程中发挥作用。

最后，在VC++集成开发环境中选择[Build/ Start Debug/Go]菜单命令，在Debug状态下运行程序，ActiveCheck也在后台开始运行了。

这时，就可以按照制定好的测试用例，对程序进行操作。凡是程序执行过的代码，如果存在错误，ActiveCheck就会记录下来。

有一个地方要说一下，在[BoundsChecker]菜单中有一项[Report Errors Immediately]，如下图所示：

图3-2 关于[BoundsChecker / Report Errors Immediately] 菜单项

该菜单项对于ActiveCheck 模式，以及下面就要介绍的FinalCheck模式的作用是一样的，即：如果不选中该项，则BoundsChecker会记录程序运行过程中发现的各种错误，直到程序结束后再进行报告；当选中该菜单项时，在程序的运行过程中，一旦BoundsChecker发现错误，会马上弹出如下的对话框进行提示：

 

图3-3 错误报告对话框

下面按图中标注的数字序号解释一下对话框中各个按钮的功能：

按钮1：点击该按钮，则表示先暂时不理会这个错误，继续执行程序。

按钮2：点击该按钮，则会马上跳转到出现问题的代码行处。处理完问题后，点击[Build/ Start Debug/Go]菜单项，可以继续执行程序，进行检测。

按钮3：点击该按钮，则将该错误添加到被忽略的错误列表中去，当再次出现这个问题时，BoundsChecker将不会进行报告。

按钮4：点击该按钮，则立即终止程序的执行。

按钮5：点击该按钮，会显示当前内存的申请、使用情况。

按钮6：点击该按钮，会得到当前这个错误的帮助信息。

按钮7、8： 这两个按钮与[BoundsChecker\Report Errors Immediately]和[BoundsChecker\ Report Errors and Event] 菜单命令的功能是完全一样的，在此不再赘述。

按钮9：点击该按钮，会显示/隐藏与该错误有关的函数调用堆栈情况，以及具体的出错代码行的位置。

是否选中[BoundsChecker／Report Errors Immediately]菜单项，完全取决于你自己的喜好，以及测试时的具体情况。如果你想要BoundsChecker在程序运行过程中实时向你汇报发现的错误，那么你就选中这个菜单项；如果想等到操作结束后，再对操作过程中BoundsChecker发现的错误统一进行分析，就不必选中这个菜单项。我在平常使用过程中更偏向于使用后一种。

3．1．2 分析错误

在你操作全部结束，退出程序后，

BoundsChecker 会显示一个所发现错误的列表。我们需要对列表中罗列的错误进行分析，来确定错误的原因和位置。

在错误检测结果列表中，罗列出了在程序的执行过程中ActiveCheck检测到的所有的内存泄露、资源泄露和API函数使用错误的相关信息。如下图所示：

 

 

图3-4 错误检测结果

在左边的窗口中，逐条列出了程序在内存、资源、API 函数使用上的问题，包括：该问题的种类，该问题发生的次数，如果是内存泄露，损失了多少内存，以及发生该问题的代码位置等等。当你用鼠标单击选中某一条记录时，在右边的窗口中会显示出与该条错误记录相对应的函数调用堆栈情况。当你用鼠标双击某一条错误记录时，会定位到引发该错误的源代码处。

    

好了，BoundsChecker在ActiveCheck模式下的使用方法至此介绍完了，是不是很简单？

在ActiveCheck模式下检测程序时，程序的运行速度基本不受影响，但其缺点是检测的错误种类有限，即只能检查出内存泄露错误、资源泄露错误、API函数使用错误。BoundsChecker 提供了另外一种检测错误的模式—— FinalCheck，也就是我们在前面提到的BoundsChecker的第二种使用模式。 FinalCheck可以检测出程序中更多的错误。下面我们就对它进行介绍。

3．2 用 FinalCheck检测更多的错误

FinalCheck具有BoundsChecker提供的所有检错功能。FinalCheck 是ActiveCheck的超集，它除了能够检测出ActiveCheck能够检测出的错误，还能发现很多 ActiveCheck 不能检测到的错误，包括：指针操作错误、内存操作溢出、使用未初始化的内存等等，并且，对于ActiveCheck能检测出的错误，FinalCheck能够给出关于错误更详细的信息。所以，我们可以把FinalCheck认为是ActiveCheck的功能增强版。我们付出的代价是：程序的运行速度会变慢，有时甚至会变的很慢。

要想在FinalCheck 模式下测试程序，不能使用VC++集成开发环境提供的编译连接器来构造程序，而必须要使用BoundsChecker提供的编译连接器来编译连接程序。当 BoundsChecker的编译连接器编译连接程序时，会向程序中插装一些错误检测代码，这也就是FinalCheck能够比ActiveCheck找到更多错误的原因。

下面就

介绍一下如何在FinalCheck模式下对程序进行测试：

1在VC++集成开发环境中打开你所要测试的项目。

2由于要使用BoundsChecker的编译连接器重新编译连接程序，所以我们为BoundsChecker独自构造一个文件夹。在VC++集成开发环境中，具体操作方法是：

A)点击[ Build/Configurations...]菜单命令。

B)在弹出的对话框中点击 Add 按钮。在Configuration 编辑框中添入你为BoundsChecker创建的文件夹的名称，这个名称是任意的，比如我们取名为BoundChecker。

C)在 Copy settings from组合框中选中 XXX—Win32 Debug项，然后点击OK按钮，接着点击Close按钮。

现在，我们已经为FinalCheck构造好了一个文件夹。

3 点击[Build/Set Active Configuration…] 菜单命令，选中你刚才为BoundsChecker建的文件夹，然后点击OK按钮。这样BoundsChecker编译连接程序时生成的中间文件、可执行程序，都会被放到该文件夹下。

4 选择[BoundsChecker/Rebuild All with BoundsChecker] 菜单命令，对程序重新进行编译连接，也就是在这时，BoundsChecker向被测程序的代码中加入了错误检测码。编译连接完成后， BoundsChecker会在你为BoundsChecker构造的文件夹中生成可执行文件。

在FinalCheck模式下对程序进行检测的准备工作都已经做好，这时可以启动程序开始测试了，

操作步骤与在ActiveChecker模式下没什么区别。具体步骤如下：

1. 确保VC++集成开发环境中[BoundsChecker/ Integrated Debugging]菜单项和[BoundsChecker/Report Errors and Events]菜单项处于选中状态。
2. 点击[ Build\Start Debug]菜单，选中“Go” 菜单项。程序开始在Debug状态下运行。
3. 按照你制定好的测试用例，对程序进行操作。  
4. 当BoundsChecker检测到了错误时，会弹出窗口向你汇报，你可以当时就进行处理，也可以等到你的操作全部完成，退出程序之后再对列出的这些错误进行分析。这完全取决于你是否选中了[BoundsChecker/Report Errors Immediately] 菜单项。  
5. 退出程序后，BoundsChecker会给出错误检测结果列表。该错误列表与ActiveChecker给出的错误列表的查看方法完全一样。只不过这个列表中所报告的信息会更多、更详细一些。   

好了，BoundsChecker在FinalCheck模式下的使用也介绍完了。ActiveChecker、FinalCheck这两种模式，比较而言各有长短。ActiveChecker使用方便，只需在Debug状态下直接运行程序即可，并且程序的运行速度较快，但检测的错误种类有限；FinalCheck模式下，需要使用BoundsChecker的编译连接器重新编译连接生成可执行程序，并且程序的运行速度比较慢，但检测的错误种类、提供的错误相关信息要多于ActiveChecker。所以，何时使用何种模式，应根据当时的具体情况而定

• 搜狐网站诚聘Java、PHP和C++工程师
• Windows7在微软WinHEC 2008上揭开神秘面纱

区别以下2种命令的进入,就知道2者区别了.也就知道为什么错了.

------------------------------------------------------------------------------------------------------------------------------

[ms]root python2.4
Python 2.4.4 (#2, Apr 15 2008, 23:43:20)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from conf.models import *
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/e/work/hainan_ms/ms/../ms/conf/models.py", line 2, in ?
    from django.db import models
  File "/usr/lib/python2.4/site-packages/django/db/__init__.py", line 7, in ?
    if not settings.DATABASE_ENGINE:
  File "/usr/lib/python2.4/site-packages/django/conf/__init__.py", line 28, in __getattr__
    self._import_settings()
  File "/usr/lib/python2.4/site-packages/django/conf/__init__.py", line 53, in _import_settings
    raise EnvironmentError, "Environment variable %s is undefined." % ENVIRONMENT_VARIABLE
EnvironmentError: Environment variable DJANGO_SETTINGS_MODULE is undefined.

------------------------------------------------------------------------------------------------------------------------------

[ms]root python2.4 manage.py shell
Python 2.4.4 (#2, Apr 15 2008, 23:43:20)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from conf.models import *
>>>

• 搜狐网站诚聘Java、PHP和C++工程师
• Windows7在微软WinHEC 2008上揭开神秘面纱

setuptools

有时候安装python的一些软件的时候会提示你setuptools之类的东西,这是这这个东西你没有安装好.所以你没有办法安装你要装大软件.

这里不再说什么原理性的东西,仅仅是说说如何安装setuptools.

1.   wget -q http://peak.telecommunity.com/dist/ez_setup.py

2.python ez_setup.py         ( 这一步必然失败,是为了第三步取得url准备的.)

运行这行的时候,linux会停留在Downling ~~~~~这类似的上面.

这是因为你的这个目录下中没有setuptools-0.6c8-py2.4.egg东西.

3.    wget http://pypi.python.org/packages/2.4/s/setuptools/setuptools-0.6c8-py2.4.egg

注意:第三步的url是根据第二步得到的url.

这时候你再运行第二步.之后再运行安装你前面不能够安装的软件.应该就解决了setuptools方面的问题了.

关键东西:是要准备好2个东西:ez_setup.py和setuptools-0.6c8-py2.4.egg.

• 搜狐网站诚聘Java、PHP和C++工程师
• Windows7在微软WinHEC 2008上揭开神秘面纱

python有一个奇怪的名字空间,就是函数与变量是不能够有相同的名字的.而且会发现没有调用查询出来的数据,却报告 'TypeError: 'ResultProxy' object is not callable'异常.

例如:

--------------------------------------------------------

mysql://root:root@127.0.0.1:33066/nxrdb
here b
Traceback (most recent call last):
  File "dns_util.py", line 37, in ?
    dns_list( dns_list )
TypeError: 'ResultProxy' object is not callable

---------code-------------------------------------------------------
from dns_config import Rt_dns, Dns_stat
import traceback

def dns_list( t_cls_list ):
    pass
#
if ( __name__ == "__main__" ):
    #dns_list( [] );
    from dbconn import DbBase
    db_2 = DbBase()
    try:
        dns_list = db_2.query( "select * from conf_correct_dns_records limit 10" )
        print "here b"
        dns_list( dns_l )
    except:
        traceback.print_exc( 5 )
    dns_list.close()
    #print len( d )

• Windows7在微软WinHEC 2008上揭开神秘面纱
• 搜狐网站诚聘Java、PHP和C++工程师

区别一下:

mysql -root -proot

#

mysql -uroot -proot

发现少了一个"u".导致了"Ignoring query to other database".

首先检查登录是否正确.再看其他的问题吧!

• 搜狐网站诚聘Java、PHP和C++工程师
• Windows7在微软WinHEC 2008上揭开神秘面纱

如果做完以下步骤,还是不能够运行,请看"-------------"以下部分,那是我个人安装经历.

linux下 D 语言编译器安装

• Windows7在微软WinHEC 2008上揭开神秘面纱
• 搜狐网站诚聘Java、PHP和C++工程师

    好久没有来写这一栏了.

    最近页是特别忙.听说奥运要封网----就是不许让他人在大型网络服务器的机房里面添加设备,和重大的修改.正好,我们的公司也是与电信打交道的,所以我们希望在这之前把上一个项目.所以我们天天加班.

    不过,现在计划出现了变动,我们的设备部门还没有准备好机器.项目只好推后了.

    在这段时间我与一个同事共同维护一个文件XXX.bat.我从数据库中每过1分钟读取一次数据库,把相应的东西写入到xxx文件.它则每过1~2分钟读取一次xxx文件.这是我之前规则.当时我就提出来,我是否在修改了xxx文件之后,马上通知你呢?他说没有必要,他每过1~2分钟就读取一次文件.

    我这边还要监听一个udp包,如是要重新flush这个文件,我立即读取数据,重写xxx文件.我这边使用的是udp监听和线程的方法,所以不会出现消耗内存的情况.

    他那边,设计为中转站,还有另一个同事写了一个模块,通知他和我的模块,数据库被修改了,我们就立即开始准备操作xxx文件.我写文件可能会出现比较慢的情况,因为数据太多.所以他那本就设计为------不断读这个文件,直到读取到---用一个while循环实现,具体条件没有查看他的.

    后来他觉得我们还是用udp通讯吧.就是我这边如果frelush数据到xxx文件中,那么就发udp包通知他.

    我们就开始了一段bug历程.

    当我把我的模块修改好,之后,就是去配置测试机器.环境搭好,我写一个sh文件作为启动程序,我们开始都能够正常运行.他的突然崩溃了.

    为什么?我不知道.你知道是什么原因吗?如果你看到这里能猜到他的程序出现了什么原因,说明你要么就是一个阅读高手,要么就是编程高手.

    他修改了一个下午程序,最后告诉我,他的程序是这样工作的:收到我的udp包还是用while循环方式去读取文件.他说问题就出在不断读取的上面导致内存(具体是内存还是死循环不是很记得了)问题.

    读取方式本身就不对,应该只读一次,就对了.

    问题说到这里,也就能够解决了,我想说的是,小心设计中间变化的问题.

    前面是好的,通信变化了,就需要考虑了.其他的也是一样类似的.

• Windows7在微软WinHEC 2008上揭开神秘面纱
• 搜狐网站诚聘Java、PHP和C++工程师

cc -lpython2.4 py_2_c.c

cc -lpython2.4 py_2_c_str.c -o a

cc -lpython2.4 adv_issue.c -o adv_issue

#include <python2.4/Python.h>
int main( int argc , char ** argv )
{
    Py_Initialize();
    PyRun_SimpleString( "print 'qqqqqqqqqqqq'" );
    Py_Finalize();
    return 0;
}

• 搜狐网站诚聘Java、PHP和C++工程师
• Windows7在微软WinHEC 2008上揭开神秘面纱

    以下内容不是适合python高手看,仅仅是为第一次看<c扩展python >引路.希望中国的孩子不要迷路.

    看了很多人的<c扩展python>,写的非常的精彩.可是却少了实际操作.这些人,都把我们当成了c高手来对待.在编译的时候仅仅是一笔带过.说什么把模块编译连接 之后就可以使用.他却不知道我是那么的菜.

    而且还给出了使用例子:

    >>import foo

    >>foo.bar( '11111' )

    5

    如果觉得自己已经了解了如何编译成python可以使用的东西,那么就不浪费你的宝贵的时间看下去了,而是给我投以鄙视的目光:这么简单的问题,还那来说.

    下面给出例子:在我的linux板块下有<Linux动态链接库编程入门>.

  /*foomain.c*/

#include <python2.4/Python.h>
/* Define the method table. */
static PyObject *foo_bar(PyObject *self, PyObject *args);
static PyMethodDef FooMethods[] = {
   {"bar",  foo_bar, METH_VARARGS},
   {NULL, NULL}
};
/* Here's the initialization function.  We don't need to do anything
 *    for our own needs, but Python needs that method table. */
void initfoo()
{
   (void) Py_InitModule("foo", FooMethods);
}
/* Finally, let's do something ... involved ... as an example function. */
static PyObject *foo_bar(PyObject *self, PyObject *args)
{
   char *string;
   int   len;
   if (!PyArg_ParseTuple(args, "s", &string))
       return NULL;
   len = strlen(string);
   return Py_BuildValue("i", len);
}

在linux下的运行: gcc -fPIC -shared -o foo.so foomain.c 这一段就ok了.

当前目录下会出现"foo.so"文件.这就是我们一直不明白那些作者说的东西.

现在在到前面python运行环境下去调用就好了(淡黄区域标示处),不会到了这一步好要我给重复给出示例吧?

• 搜狐网站诚聘Java、PHP和C++工程师
• Windows7在微软WinHEC 2008上揭开神秘面纱

Linux动态链接库编程入门
 

动态链接库是一种通用的软件组件技术，是多种操作系统中提供基本服务的方式。比如 Win32 内核就是 3 个 DLL 文件构成。这种技术在 Linux 操作系统下也有对应的实现，就是 Linux 标准对象 Standard Ojbect ，对应的文件扩展名为 .so 。

  下面通过一个简单的例子开始介绍 Linux 标准对象。

  我们的标准对象文件含有一个函数，不需要声明 export 导出符号，只需要编译器设置即可。如下：

#include <stdio.h>

#include <stdlib.h>

void show() {

  printf("Standard Object by gashero\n");

}

  保存为 myso.c 文件，按照如下编译：

$ gcc -fPIC -shared -o libmyso.so myso.c

  执行生成一个 libmyso.so 文件，按照 Linux 标准对象的命名惯例，应该在库名称之前加上 "lib" 前缀，尽管不是必须的。编译开关 -fPIC 代表函数符号可以重定向， -shared 代表编译结果是一个标准对象。

  不同于 Win32DLL ， Linux 标准对象中的所有函数都是直接导出的，都可以被调用程序所访问。下面我们编写调用程序：

#include <stdio.h>

int main() {

  printf("Invoke my so\n");

  show();

  return 0;

}

  保存为 invoke.c ，按照如下 gcc 开关编译：

$ gcc -o test invoke.c ./libmyso.so

  编译生成 test 可执行文件。如上编译条件的最后一条需要是所调用的标准对象文件名，注意必须含有路径。如果只是使用 libmyso.so ，则必须确保这个文件在可访问的 PATH 下面。本例所使用的文件名 "./libmyso.so" 是当前路径下的，使用了相对路径。

  如下测试结果：

$ ./test

Invoke my so

Standard Object by gashero

  希望上文的例子可以对大家有所帮助，这也是我的毕业设计题目，待我完成之后会有一份更加完整的文档介绍 Win32DLL 和 Linux.so 的。

• Windows7在微软WinHEC 2008上揭开神秘面纱
• 搜狐网站诚聘Java、PHP和C++工程师

来源于:http://www.ibm.com/developerworks/cn/linux/sdk/python/pyzo/index.html

用 C 扩展 Python 和 Zope 两全其美

文档选项 将此页作为电子邮件发送 级别： 初级 Michael Roberts (michael@vivtek.com ), 业主, Vivtek 2001 年 8 月 01 日 一旦明白怎样用 C 扩展 Phthon，您就会知道这很容易，把 Python 扩展封装到 Zope 中也同样容易。难点是如何从各式各样的文档集中找到那些您需要的重要信息，而 Michael 已在本文帮您收集了这些信息。 有几个原因使您可能想用 C 扩展 Zope。最可能的是您有一个已能帮您做些事的现成的 C 库，但是您对把它转换成 Python 却不感兴趣。此外，由于 Python 是解释性语言，所以任何被大量调用的 Python 代码都将降低您的速度。因此，即使您已经用 Python 写了一些扩展，您仍然要考虑把其中最常被调用的部分改用 C 来写。不论哪种方式，扩展 Zope 都是从扩展 Python 开始。此外，扩展 Python 会给您带来其它的好处，因为您的代码将可以从任何 Python 脚本访问，而不只是从 Zope。这里唯一要提醒的是在写本文的时候，Python 的当前版本是 2.1，但是 Zope 仍然只能和 Python 1.5.2 一起运行。对 C 扩展来说，两个版本并没有什么变化，但如果您有兴趣对您的库进行 Python 包装，又想让它们都能在 Zope 下工作，您就得注意不要使用任何比 1.5.2 更新的东西。 Zope 是什么？ Zope 代表“Z Object Publishing Environment（Z 对象发布环境）”，它是用 Python 实现的应用程序服务器。“太棒了，”您说，“但应用程序服务器的确切含义是什么呢？”应用程序服务器就是一个长期运行的进程，它为“活动的内容”提供服务。Web 服务器在运行期间调用应用程序服务器来构建页面。 扩展 Python：有趣又有益 想扩展 Zope，您首先要扩展 Python。虽然扩展 Python 不像“脑外科手术”那样复杂，但也不像“在公园中散步”那样悠闲。有两个基本组件用于 Python 扩展。第一个显然是 C 代码。我将马上探讨它。 另一个部分是 安装文件 。安装文件通过提供模块名称、模块的 C 代码的位置和您可能需要的所有编译器标志来描述模块。该文件被预处理，以创建 makefile（在 UNIX 上）或 MSVC++ 工程文件（MSVC++ project file，在 Windows 上）。先说一下 ― Windows 上的 Python 事实上是用 Microsoft 编译器编译的。Python.org 的人也推荐用 MSVC++ 编译扩展。显然，您应该能够成功说服 GNU 的编译者们，但我本人还没试过。 无论如何，还是让我们来定义一个叫做‘foo’的模块吧。‘foo’模块会有一个叫做‘bar’的函数。当我们要使用时，我们可以用 import foo; 来把这个函数导入到 Python 脚本中，就跟导入任何模块一样。安装文件非常简单： 清单 1. 一个典型的安装文件 # You can include comment lines. The *shared* directive indicates # that the following module(s) are to be compiled and linked for # dynamic loading as opposed to static: .so on Unix, .dll on Windows. *shared* # Then you can use the variables later using the $(variable) syntax # that 'make' uses. This next line defines our module and tells # Python where its source code is. foo foomain.c 回页首 编写代码 那么我们实际上该怎样写 Python 知道如何使用的代码呢，您问？ foomain.c （当然，您可以随意命名它）文件包含三项内容：一个方法表，一个初始化函数和其余的代码。方法表简单地将函数名与函数联系起来，并告知 Python 各个函数所使用的参数传递机制（您可以选择使用一般的位置参数列表或位置参数和关键词参数的混合列表）。Python 在模块装入时调用初始化函数。初始化函数将完成模块所要求的所有初始化操作，但更重要的是，它还把一个指向方法表的指针传回给 Python。 那我们就来看看我们的小型 foo 模块的 C 代码。 清单 2. 一个典型的 Python 扩展模块 #include <Python.h> /* Define the method table. */ static PyObject *foo_bar(PyObject *self, PyObject *args); static PyMethodDef FooMethods[] = { {"bar", foo_bar, METH_VARARGS}, {NULL, NULL} }; /* Here's the initialization function. We don't need to do anything for our own needs, but Python needs that method table. */ void initfoo() { (void) Py_InitModule("foo", FooMethods); } /* Finally, let's do something ... involved ... as an example function. */ static PyObject *foo_bar(PyObject *self, PyObject *args) { char *string; int len; if (!PyArg_ParseTuple(args, "s", &string)) return NULL; len = strlen(string); return Py_BuildValue("i", len); } 深入研究 我们来看会儿这些代码。首先，请注意您必须包含 Python.h 。除非您已在包含路径（include path）中设置了该文件的路径，否则您可能需要在安装文件中包含 -I 标志以指向该文件。 初始化函数必须命名为 init <模块名>，在我们的例子中是 initfoo 。初始化函数的名称，毫无疑问，是 Python 在装入模块时所知道的关于模块的全部信息，这也是初始化函数的名称如此死板的原因。顺便说一下，初始化函数必须是文件中唯一未被声明为 static 的全局标识符。这对静态链接比对动态链接更重要，因为非 static 标识符将是全局可见的。对动态链接来说，这不是一个很大的问题，但如果您打算在编译期间链接所有东西，又没有把所有可以声明为 static 的东西声明为 static ，那么您很可能就会碰到名称冲突的问题。 现在我们来观察实际的代码，看看参数是怎样被处理的，返回值又是怎样被传递的。当然，一切都是 PyObject ― Python 堆上的对象。您从参数中得到的是一个对“this”对象的引用（this 用于对象方法，对类似 bar() 这样的无参数的老式函数来说是 NULL）和一个存储在 args 中的参数元组。您用 PyArg_ParseTuple 找回您的参数，然后用 Py_BuildValue 把结果传回去。这些函数（还有更多）都归档在 Python 文档的“Python/C API”部分中。不幸的是，没有按名称排列的简单的函数清单，文档是按主题排列的。 另请注意，函数在出错的情况下返回 NULL。返回 NULL 表示出错了；如果想让 Python 做得更好，您应该抛出异常。我会指点您去查阅关于如何做这件事的文档。 回页首 编译扩展 现在剩下的全部问题是编译模块。您可以通过两种方式进行。第一种是按照文档中的指导，运行 make -f Makefile.pre.in boot ，这样将会使用您的 Setup 来编译一个 Makefile。然后您就用该 Makefile 编译您的工程。这种方式只适用于 UNIX。对 Windows 来说，存在一个叫“compile.py”的脚本（请参阅本文后面的 参考资料 ）。原始脚本很难找到；我从一个邮件列表中找到了一个来自 Robin Dunn（wxPython 的幕后工作者）的被大量改动了的副本。这个脚本能在 UNIX 和 Windows 上工作；在 Windows 上，它将从您的 Setup 开始编译 MSVC++ 工程文件。 要进行编译，您必须使包含的文件和库都可用。Python 的标准 Zope 安装没有包含这些文件，因此您需要从 www.python.org（请参阅 参考资料 ）安装 Python 的常规安装。在 Windows 上，您还必须从源代码安装的 PC 目录中获取 config.h 文件；它是 UNIX 安装为您编译的 config.h 的手工版。因此，在 UNIX 上，您应该已经拥有它了。 一旦这些都完成后，您就会得到一个以“.pyd”为扩展名的文件。把这个文件放到 Python 安装目录下的“lib”目录（在 Zope 下，Python 位于“bin”目录，因此您的扩展得结束于“bin/lib”目录，奇怪吧。）然后您就可以调用它了，就像调用任何源生的 Python 模块一样。 >>> import foo; >>> foo.bar ("This is a test"); 14 做到这里时，我的第一个问题是问自己该如何用 C 定义从 Python 中可见的 类 。事实上，我可能问了一个错误的问题。在我已研究的示例中，特定于 Python 的一切都只 用 Python 来完成，也都只调用从您的扩展中导出的 C 函数。 回页首 把它带到 Zope 中去 一旦完成了您的 Python 扩展，下一步就是使 Zope 能和它一起工作。您有几种方式可以选择，但在一定程度上，您希望您的扩展以什么方式与 Zope 一起工作将首先影响到您编译扩展的方式。从 Zope 内使用 Python（以及用 C 所做的扩展）代码的基本方式是： 如果函数很简单，您可以把它当作一个变量。这些被叫做“外部方法”。 更复杂的类，可以从 Zope 脚本中调用（这是 Zope 2.3 的一个新功能）。 您可以定义一个 Zope Product，然后可以用 ZClass（一组已做好的、Web 可访问的对象）扩展它，在脚本中使用它，根据它的自有权限发布它（它的实例被当作页来对待）。 当然，您自己的应用程序可以使用这些方式的组合。 回页首 创建外部方法 从 Zope 调用 Python 的最简单的方式是把您的 Python 代码做成 外部方法 。外部方法是被放到 Zope 安装目录下的“Extensions”目录中的 Python 函数。一旦那里有了这样一个 Python 文件，您就可以转到任意文件夹，选择“添加外部方法”，并添加调用要使用的函数的变量。然后您就可以往该文件夹中显示调用结果的任意页添加 DTML 字段。我们来看一个使用了上面所定义的 Python 扩展 ― foo.bar ― 的简单示例。 首先，来看扩展本身：我们把它放到一个例如叫 foo.pyd 的文件中。记住，这个文件位于 Zope 下的 Extensions 目录。为了能够顺利进行，当然，我们在上面创建的 foo.pyd 必须在位于 bin/lib 的 Python 库中。一个出于这个目的的、简单的包看起来可能像这样: 清单 3. 一个简单的外部方法（文件：Extensions/foo.py） import foo def bar(self,arg): """A simple external method.""" return 'Arg length: %d' % foo.bar(arg) 很简单，不是吗？它定义了一个可以用 Zope 管理界面附加到任意文件夹的外部方法“bar”。要从该文件夹中的任何页中调用我们的扩展，我们只需简单地插入一个 DTML 变量引用，如下所示： <dtml-var bar('This is a test')> 当用户查看我们的页时，DTML 字段将被文本“Arg length: 14”代替。我们就这样用 C 扩展了 Zope。 回页首 Zope 脚本：Cliff Notes 版 Zope 脚本是 Python 2.3 的一个想用来代替外部方法的新功能。外部方法能做到的，它都能做到，而且它能和安全性及管理系统更好地集成，在集成方面提供更多的灵活性，它还有很多对 Zope API 中公开的全部 Zope 功能的访问。 一个脚本基本上就是一个短小的 Python 程序。它可以定义类或函数，但不是必须的。它被作为对象安装在 Zope 文件夹中，然后就可以把它当作 DTML 变量或调用（就像一个外部方法）来调用或者“从 Web 中”（在 Zope 中的意思就是它将被当作页来调用）调用它。当然，这意味着脚本可以像 CGI 程序那样生成对表单提交的响应，但却没有 CGI 的开销。确实是一个很棒的功能。此外，脚本有权访问被调用者或调用者对象（通过“context”对象）、对象所在的文件夹（通过“container”对象）和其他一些零碎信息。要获得更多关于脚本的知识，请参阅 Zope 手册（请参阅 参考资料 ）中的“高级 Zope 脚本编制（Advanced Zope Scripting）”那一章。 您可能会错误地认为可以直接从脚本简单地导入 foo 并使用 foo.bar（我知道我确实犯过这种错误）。但事实并非如此。由于安全性限制，只有 Product 可以被导入，而不是什么模块都可以。一般而言，Zope 的设计者们认为任何脚本编制都需要访问文件系统，既然脚本对象是由 Web 使用 Zope 管理界面来管理，所以它们不是完全可信的。所以我打算就此打住，不给您展示示例脚本了，而是来讨论 Product 和基础类。 回页首 专注于 Product Product 是扩展 Zope 的强大工具方法。从安装目录的级别来看，Product 就是位于 Zope 目录下的“lib/python/Products”目录中的一个目录。在您自己的 Zope 安装目录中，您可以看�