| Profil de 威我只是风的影子，根本不存在的东西PhotosBlogListes |  Outils  Aide |
|
30 mai 我还是启用这个blog吧毕竟这里留下了我好多的东西。。。 但是新的也继续，并且有更多的内容 http://hi.baidu.com/python23/ 也欢迎访问我的技术blog: http://www.pythonid.com 这个是在csdn的blog 8 juin C++中的内存泄露问题 最近几天都在解决一个daemon的内存泄露问题，是用来做信息过滤的，并且是多线程的。
刚刚写完这个程序的时候就发现有内存泄露，平均1000次处理信息后会泄露502K，很严重。 之前我曾经做过一些C程序的内存泄露的检查，C的比较好办一些，只要有内存泄露肯定是 有malloc而没有对应的free, 而由于C++语言本身的复杂性，它的内存泄露检测就没有这么简单了。 比如下面这种情况：
char *test = new char[10];
delete test; 确实是用了delete的，但是写错了，应该是 delete []test 才正确。
还有以下的情况： #include <iostream>
#include <string> using namespace std;
class VBase
{ public: virtual ~VBase(){} // 如果没有这行，就不能释放Test中分配的内存 virtual void test() = 0; }; class Test : public VBase
{ public: Test(){} ~Test(){} virtual void test(){} }; int main() { VBase *vb; Test *test = new Test(); vb = test; delete vb; return 0; } 子类Test被分配了内存空间，可是释放的时候是从父类VBase的指针释放的，这种情况， 如果父类的析构函数不是虚函数，就不会调用子类的析构函数（即使父类是抽象类也是如此！）， 从而导致子类中分配的内存不能释放。 对C++语言的掌握不仅仅是能写出可以正确运行的程序来！ 能写出稳定、高效、灵活且没有内存泄露的程序来的才算C++用的好。 27 avril 把库的搜索路径编译到程序中 通常在linux下的程序都会依赖一堆的so，系统会在/etc/ld.so.conf中定义的路径中寻找这些
动态库。比如装了一个软件，它有一些自己的so，在/opt/myproduct/lib下，很可能它会修改 /etc/ld.so.conf，把/opt/myproduct/lib添加进去，以便自己的程序使用的时候能找到。但这样 引入了一些潜在的问题，容易出来版本混乱，就象我前面遇到的问题，下面两个地方都有同一个库： libfreetype.so.6 => /usr/lib/libfreetype.so.6 libfreetype.so.6 => /opt/gd/lib/libfreetype.so.6 其中第一个是系统的，第二个是由于安装其他软件给附带安装上的，这两个libfreetype.so.6都是 符号连接，系统的是连到libfreetype.so.6.3.8，第二个是libfreetype.so.6.3.7，就这一点小小 的差别就让我的一些程序不能运行，虽然说这也和这个库的设计有关，但这种情况是可以避免的。 就是在gcc编译的参数里带上库的搜索路径，很简单，比如 gcc -Wl,-R/opt/myproduct/lib ...
就把/opt/myproduct/lib带到了编译好的程序中，改程序运行的时候会先到这个路径中搜索库。 这样就不需要通过把/opt/myproduct/lib添加到/etc/ld.so.conf中这种修改系统的办法来达到目的。 16 mars python 小技巧
但是还有一种情况，就是如果我有个模块在site-packages里，是一个目录的形式，名字叫 zwtest-0.1，这时候想要import这个模块的话，应该写成： import zwtest-0.1 但是这样就很不爽了，如果出了 zwtest-0.2，连import都的改，有一办法就是在与zwtest-0.1相同目录里建立一个zwtest.pth的文件，里面内容是zwtest-0.1，这样python在查找模块的时候，会把zwtest.pth中的模块全部当成名为zwtest的模块，这时候 import zwtest 就和import zwtest-0.1效果一样了，就是升级了版本，只需要修改zwtest.pth就好了，而且也很好的解决了一个模块的多版本共存问题。并且，*.pth中是可以写多个模块的，一行写一个就行，很cool。 又是符号未定义发现GNOME的东东版本的一致性好难控制，GNOME自己是由很多LIB组合起来 的，这些LIB互相依赖，如果其中一个LIB的版本错了，可能一些程序运行起来很正 常，而还有一些程序就会出问题。 今天在LINUX上装了 pyGTK 和wxPython2.6.2, 他们都是使用GTK的，装好后无 法运行我的程序，报一错误：undefined symbol: FT_GlyphSlot_Embolden(/usr/lib/libcairo.so.2)，这样的东西见的太多了，通 常就是和库的版本有关。很恶的问题，记得wxPython在2.6.2版本之前装在比较新 的GNOME上就会有这个错误：undefined symbol: pango_x_get_context，只要 wxPython换到版本2.6.2就好了，这个问题曾经困扰了我好久。 先看看使用的SO的情况，用ldd /usr/lib/libcairo.so.2， 显示： linux-gate.so.1 => (0xffffe000) libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40075000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4007d000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40176000) libpng12.so.0 => /opt/gd/lib/libpng12.so.0 (0x40184000) libglitz.so.1 => /usr/lib/libglitz.so.1 (0x401c3000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x401e7000) libfreetype.so.6 => /opt/gd/lib/libfreetype.so.6 (0x40218000) libz.so.1 => /lib/libz.so.1 (0x4027d000) libm.so.6 => /lib/tls/libm.so.6 (0x40290000) libc.so.6 => /lib/tls/libc.so.6 (0x402b6000) libdl.so.2 => /lib/libdl.so.2 (0x403d5000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x403d9000) /lib/ld-linux.so.2 (0x80000000) 果然有问题，libfreetype连错了，它用的是 /opt/gd/lib 下的。在/opt/gd/lib 下的是libfreetype.so.6.3.7， 而我的/usr/lib下的是 libfreetype.so.6.3.8， 版本不一样，就出了问题。至于为什么会连到那个so，是因为我的机器上装了一个 软件，它会安装一个gd，并且装到那个目录，还把/opt/gd/lib加到 了/etc/ld.so.conf中去。问题清楚了，去/etc/ld.so.conf中删除/opt/gd/lib 行，用root用户重新执行ldconfig重新配置了库信息就OK了，再次用 ldd /usr/lib/libcairo.so.2 看到的结果就正常了： linux-gate.so.1 => (0xffffe000) libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40075000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4007d000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40176000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x40184000) libglitz.so.1 => /usr/lib/libglitz.so.1 (0x401c3000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x401e7000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40218000) libz.so.1 => /lib/libz.so.1 (0x4027d000) libm.so.6 => /lib/tls/libm.so.6 (0x40290000) libc.so.6 => /lib/tls/libc.so.6 (0x402b6000) libdl.so.2 => /lib/libdl.so.2 (0x403d5000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x403d9000) /lib/ld-linux.so.2 (0x80000000) 其实像这样的问题，在 LINUX 下是经常出现的，而在Windows下是不容易出这样的 问题的。这个可能和两个系统的发展有关，windows下的绝大部分为商业软件，所 以基本上都会使用自己的库，没有什么开源的东西，不会像LINUX上的程序一样， 很多软件都组合了N多的开源东东。 有利也有弊，这个给LINUX系统带来很多不确 定性，造成一些依赖其他库太多的程序的稳定性不够，一是不能控制别人的程序的 质量，再者，版本的一致性问题到现在没有太好的解决办法，这很容易造成混乱。 28 février Windows2000/XP中强制杀进程的方法这个我也是从网上看到的，觉得挺有用的，2000里面很多进程都是从任务管理器里杀不掉的。
Windows 2000:
ntsd -c q -p 进程ID
注意：System、SMSS.EXE和CSRSS.EXE不能杀，CSRSS.EXE是Win32子系统。
Windows XP:
tasklist 列出系统中正在运行的进程信息
tskill 进程ID 结束该进程ID的进程
|
||||
|
|
