推荐电影Persepolis

 一部反映伊朗的电影,管他感觉真不真实,反正感觉很异样。
特别推荐对国家的制度,改革有想法,和当前在英国感叹西方社会如何公平美好的人看一看,也许会有些许改变。国家是一个很复杂的东西。

这里是内容(frome douban)
简体中文名: 我在伊朗长大

导演: Vincent Paronnaud / Marjane Satrapi
主演: Catherine Deneuve / Danielle Darrieux / Simon Abkarian

官方网站: http://www.vertigofilms.es/persepolis/
上映年度: 2007
语言: 法语
制片国家/地区: 法国
又名: 茉莉人生 / 波斯波利斯

imdb链接: tt0808417

电影改编自伊朗女插画家Marjane Satrapi的同名漫画,以自传的形式讲述了自己的成长经历,反映了伊朗的社会变迁。
  1979年之后,伊朗发起了伊斯兰教革命,社会动荡不安,革命的失败更使伊朗失去民主的希望,日渐保守,人民苦不堪言。九岁的Marjane早熟、敏感,她聪明地瞒过官方爪牙,迷上了西方朋克乐队和流行音乐,沉浸在自己的世界。
  两伊战争爆发之后,伊朗的生活更加艰难,Marjane渐渐长大,越来越大胆的行为让父母担心不已,她14岁那年,被父母送到了奥地利上学。
  在奥地利,Marjane身为一个伊朗人,不得不面对别人的歧视和自卑的情绪。当她终于克服了心理障碍,赢得大家认可的时候,爱情的伤痛和对家乡的思念,却使她决定回到父母身边。
  此时的伊朗,依然经历着战火的洗礼,宗教对妇女生活的限制越发严苛,Marjane开始怀疑自己是否应该在这个充满专制的国度继续生活下去。

内存泄漏测试工具

    随着测试的进一步深入,我觉得问题开始出现在内存分配等等细节。于是去网上搜有没有什么自动测试内存泄漏的工具,因为在Visual C++的环境里,我曾经获得过这样的工具。结果还真的有,而且更好。这个工具叫valgrind。它的官方网站是http://valgrind.org/,现在的最高版本3.3.0。不过我并没有安装,因为Fedora7原来已经安装了valgrind3.2.3,已经够用了。
    这个软件有很多的参数可选。直接将执行文件提供给这个软件,他就会通过运行这个软件,测试软件中所有的内存泄漏。最特殊的好处是,它可以识别gcc的-g选项加载入执行文件的调试信息,直接报出源文件的哪一行可能产生内存泄漏。而且它会以可能产生和已经产生的方式报告内存泄漏。全面程度超乎我的想象,有些报告我根本无法判别为何出现内存泄漏。也许是我对C++的理解还不够,毕竟以前都是编标准C。
    在Visual C++,无论是VC6还是.net环境,也有一个小插件可以使用。以前在调试多线程的时候用过,还是不错的。这个叫vld(Virtual Leak Detector),网站是http://www.codeproject.com/KB/applications/visualleakdetector.aspx。只需要加载一个头文件和动态链接库,就可以在调试报告中拿到所有没有释放的内存信息,包括内存区大小,块数,内容等等。不过不能报告是在哪里出现了问题。
 
Dectect the Memory Leakage in C and C++
 
Under Linux enironment, there is a debug tool to check the memory leakage: valgrind. As far as the -g flag has been added when compiling the source code by gcc or g++, the valgrind can tell which line in the source code causes the memory leakage, along with the size and block number.
 
I think many Linux OSs have already added this tool into the development environment. At least on my Fedora7, I can directly use it, version 3.2.3. The official webpage of this tool: http://valgrind.org/
 
And if you are using the Microsoft Visual C++, no matter 6.0 or .net, there is also a small pluge which can detect the memory leakage, a tool named "Virtual Leakage Detector". This is not as powerful as valgrind, however, it is already instructive to debug and easy to use. To get it, visit http://www.codeproject.com/KB/applications/visualleakdetector.aspx.

编程就是灾难

    从上个星期到现在,就像过山车一样,一下子到了山顶,然后又跌了下来。
    上个星期解决了那个bug之后,我终于能够在自己的代码上开始对以前的模型做改动。先是在路由器结构里面加了一个功能-方向对应表。然后小测了一下,发现我作改动之后整个网络的通讯速度上升10%到300%不等。可以说是第一步成功了。
    但是,测试了各种拓扑参数的组合,有些测例下,GCC编译的仿真会崩溃,NCSIM倒是可以通过;然后有些会在仿真中间崩溃。调试了3天,解决了中间崩溃的问题,又是一个特例造成的。但是,那个GCC不能仿真的问题差点没把我气死。
    不过,首先要说,GDB真的是很爽,很牛逼!
    我现在基本上就靠它了。(这还要感谢一下王芸同学,是她提醒的,呵呵。)不光能在崩溃的时候能告诉我死在哪了,还能多文件设断点,查看堆栈,查看内存,感觉和VC6的调试环境没区别了,除了是用命令行的。以后谁用GCC编程,都要记得用这个,方便大发了。
 
    看看,这就是我的错误:
Program received signal SIGSEGV, Segmentation fault.
0x00577b0d in __printf_fp () from /lib/libc.so.6
 
    又是讨厌的SIGSEGV错误。而且死在了共享库!还好学会了用栈查看,得到以下信息:
(gdb) bt
#0  0x00577b0d in __printf_fp () from /lib/libc.so.6
#1  0x005720cd in vfprintf () from /lib/libc.so.6
#2  0x0057afe2 in fprintf () from /lib/libc.so.6
#3  0x080527ce in occn::StatInstant::stat_write_to_gui (this=0x8ab8950, _time=51142, _value=620.25126345299407) at ../occn/src/stats/StatInstant.cpp:262
#4  0x08052a0e in occn::StatInstantCAvg::stat_write (this=0x8ab8950, _time=51142, _value=0) at ../occn/src/stats/StatInstant.cpp:358
#5  0x080528d1 in occn::StatThroughput::stat_write (this=0x8ab8950, _time=51142, _value=0) at ../occn/src/stats/StatInstant.cpp:310
#6  0x0806322b in MasterFlit::LinkLayer_receive (this=0x8b96840) at src/MasterFlit.cpp:93
#7  0x08062628 in MasterFrame::TransportLayer_receive (this=0x8b94740) at src/MasterFrame.cpp:21
#8  0x08058f28 in transmitter::action_rx (this=0x8b92308) at src/transmitter_receiver.h:163
#9  0x0807b150 in sc_core::sc_process_b::execute (this=0x8b945b0) at ../../../../src/sysc/kernel/sc_process_int.h:96
#10 0x080771b2 in sc_core::sc_thread_cor_fn (arg=0x8b945b0) at ../../../../src/sysc/kernel/sc_process_int.cpp:453
#11 0x0809cee1 in sc_cor_qt_wrapper (arg=0x8b945b0, cor=0x906f280, fn=0x807719a <sc_core::sc_thread_cor_fn(void*)>) at ../../../../src/sysc/kernel/sc_cor_qt.cpp:163
#12 0x080a12b0 in ?? () at /usr/local/include/c++/3.2.3/iostream:62
 
    所以源代码的最后一句是../occn/src/stats/StatInstant.cpp:262
    这里的代码是这样的:
(gdb) list  ../occn/src/stats/StatInstant.cpp:262
257
258         // dump cache table
259         if ((this->cache_table_ptr == this->cache_size) && (this->cache_table_ptr > 0)) {
260
261             for (i = 0; i < this->cache_table_ptr; i++)
262               fprintf(fp, "%f %fn", this->cache_table[i].time, this->cache_table[i].value);
263            
264             fflush(this->fp);
265
266             this->cache_table_ptr = 0;
    也就是说fprintf(fp, "%f %fn", this->cache_table[i].time, this->cache_table[i].value);这句话导致内存指向错误。开始以为是下标越界,可偏偏最后发现这里的i是0。后来以为this->cache_table[i].value这里的double向%f这种float强制转换出现了问题,但后来发现也没问题。
    终于,抱着必死的决心,在这句话之前,加了一个读取文件信息的语句,cout << ftell(fp) << endl;
    结果,改这里崩溃了。最直接的假设,fp==NULL。可是偏偏不是。通过检查内存和单步跟踪,那个fp偏偏是对的,而且这个文件在几千条语句之前还正确操作过,而这个fp指针从来就没有关闭过!
    整了一天,我终于无奈了。不得不假设,这个版本的libc也许有问题吧,至少ncsc用的gcc和lib能通过并且不崩溃。
    如果你遇到这样的古怪事情,你怎么办?别建议我装一个其他版本的libc,整个能用的toolchain可不容易。
    最后,今天晚上,我把所有用fprintf的语句,和所有的什么fopen之类的,全部改成ofstream的标准C++流操作了。终于在GCC下工作了。难道这就是C++的cout比printf好的地方,呵呵,挺搞的。
   
    这几天脑袋快疯掉了,什么问题都有,程序有时候就是跟你做对。有时候觉得自己编C语言都快7年了,成天还是被程序整来整去的。
    在查网页浏览记录的时候,发现有个外国人挺好玩的。用google查到了我关于ncsc的文章,看不懂,居然用google translation去看翻译版。所以决定,专业相关的内容,会附上个英文版。
Problem of the C style file processes
 
During the debugging today, my code crash at a SIGSEGV signal. I am using GCC-3.2.3, SystemC2.1, Fedora 7, Linux 2.6.23.12.
Using the gdb debug tool, the crash looks like:
 
 Program received signal SIGSEGV, Segmentation fault.
 0x00577b0d in __printf_fp () from /lib/libc.so.6
 (gdb) bt
 #0  0x00577b0d in __printf_fp () from /lib/libc.so.6
 #1  0x005720cd in vfprintf () from /lib/libc.so.6
 #2  0x0057afe2 in fprintf () from /lib/libc.so.6
 #3  0x080527ce in occn::StatInstant::stat_write_to_gui (this=0x8ab8950, _time=51142, _value=620.25126345299407) at ../occn/src/stats/StatInstant.cpp:262
 #4  0x08052a0e in occn::StatInstantCAvg::stat_write (this=0x8ab8950, _time=51142, _value=0) at ../occn/src/stats/StatInstant.cpp:358
 #5  0x080528d1 in occn::StatThroughput::stat_write (this=0x8ab8950, _time=51142, _value=0) at ../occn/src/stats/StatInstant.cpp:310
 #6  0x0806322b in MasterFlit::LinkLayer_receive (this=0x8b96840) at src/MasterFlit.cpp:93
 #7  0x08062628 in MasterFrame::TransportLayer_receive (this=0x8b94740) at src/MasterFrame.cpp:21
 #8  0x08058f28 in transmitter::action_rx (this=0x8b92308) at src/transmitter_receiver.h:163
 #9  0x0807b150 in sc_core::sc_process_b::execute (this=0x8b945b0) at ../../../../src/sysc/kernel/sc_process_int.h:96
 #10 0x080771b2 in sc_core::sc_thread_cor_fn (arg=0x8b945b0) at ../../../../src/sysc/kernel/sc_process_int.cpp:453
 #11 0x0809cee1 in sc_cor_qt_wrapper (arg=0x8b945b0, cor=0x906f280, fn=0x807719a <sc_core::sc_thread_cor_fn(void*)>) at ../../../../src/sysc/kernel/sc_cor_qt.cpp:163
 #12 0x080a12b0 in ?? () at /usr/local/include/c++/3.2.3/iostream:62  
 (gdb) list  ../occn/src/stats/StatInstant.cpp:262
 257
 258         // dump cache table
 259         if ((this->cache_table_ptr == this->cache_size) && (this->cache_table_ptr > 0)) {
 260
 261             for (i = 0; i < this->cache_table_ptr; i++)
 262               fprintf(fp, "%f %fn", this->cache_table[i].time, this->cache_table[i].value);
 263            
 264             fflush(this->fp);
 265
 266             this->cache_table_ptr = 0;
 
After check, the problem of the code
 fprintf(fp, "%f %fn", this->cache_table[i].time, this->cache_table[i].value);
lies on the file poniter fp. However, this fp is not a NULL pointer, and correct it is at runtime.
 
Finally, I cannot find out the underlying reason of this problem. My suggestion is:
If you can, change the libc library. Since the same code can work and run under NCSC (GCC3.2.95 and stand-alone libc lib).
Or, change the code style to C++. Using the ofstream can solve this.

英国的酒和年轻人

今天晚上看新闻,不知怎么的,就是觉得该记下来,就写下来了。
 
十月份,Cashire,3个不到18岁的英国年轻人,在喝了7个小时的酒之后,在街上走。在Garry Newlove的家前踢他老婆的车。Garry Newlove出来阻止,结果被他们打,把脑袋当足球踢,当着Garry Newlove的小女儿的面,把她父亲踢昏,最后死在医院。
 
今天,过了3个月,经过数次的问询之后,Crown Court终于判处他们有罪。当BBC North West Tonight主持人Gordon Burns逼问Cashire的Chief Police Officer有什么改进的时候,警官回答:
 
I think I must be very clear here.
Unless we have seen a change in the drinking culture of this country, as somewhere in this country we will see another tragedy as Garry Newlove.
Where we have a drinking culture that somehow condone and accept that drinking to access or drinking for the simple second to getting drunk, then we must accept that the behavior is out of control.
Every weekends, every town of city….,the place of drunkness, unfortunately send message to the young people, that some alcohol should be condoned or behavior should be emulated.
 
无语了。我只能说,this is the crrent England.

一个星期的调试

今天不得不记录一下,一个星期了,除了周六和周日,每天在实验室调代码5个小时以上,今天终于找到错误,加了不到10个字母,它对了。
 
    上个星期开始,我开始实施自己的第二阶段计划,继续更改我的路由器结构。上周二的时候,我以为我对了,因为在4×4 5功能的时候它工作正常。但是当我改到4×4 6功能的时候,就不工作了。于是,漫长的调试开始。
    开始的时候,我还耐心的看打印报告。看着看着,看了大概几百行了,没有发现问题。可是1毫秒运行的打印报告有44MByte,而确定发生错误的时间在100微秒之后,已经有数万行打印报告了。
    不行,人眼看是看不过来的。周四,我终于下决心写一个程序去检查打印报告。呵呵,打印报告就是调试用的,我还要写一个程序去自动化的检查调试结果。到了今天上午,我终于调试完了检查程序,拿检查程序去检查1毫秒的调试报告。它居然在检查了10分钟后,告诉我没有问题!
    最后,我不得不去想这个过程中的问题。检查程序唯一不能检查就是网络接口和处理器的部分。也就是说,有可能我的路由器真的对了,而是其他部分出了什么问题。终于,在下午,我发现编号[1.0]的处理器在1微秒的时候死掉了,并且它是唯一个4号功能的处理器。没有了4号功能,所有其他处理器在发出4号功能报文的时候,都会失败,也会死掉。
    发现了问题,反复打印新的调试报告,检查,终于在添加了一个判断条件之后,它工作了。
 
    成绩小小的,过程艰巨的。
 
    呵呵,另外一件事。上周三我做了在英国的第一次演讲,课内的,讲自己的研究题目。国内这种演讲也多次了吧,不过拿英文是第二次,听众是外国人的是第一次。讲的不错,大家没什么问题,说我讲的清楚。呵呵,感觉还不错。贴上ppt,不过估计不听我说是看不懂的。呵呵,一贯风格,图加标题。

linux编程_两个小问题

今后注定被Linux折磨。今天遇到两个问题,写下来,也许以后有人会遇到。
 
今天调程序,出了个怪问题。用g++生成的应用程序执行的时候出现错误:
 /usr/local/lib/libgcc_s.so.1: version `GCC_3.3′ not found (required by /usr/local/lib/libstdc++.so.5)
该错误在较高版本的Linux和自己编译过GCC的时候可能会遇到。
根据http://china.xilinx.com/support/answers/20154.htm上的办法,将/lib连接路径的优先级提高可以解决问题
在.bashrc或者.cshrc中添加LD_LIBRARY_PATH=/lib:$LD_LIBRARY_PATH可解决问题。
 
另外,程序运行时出现Segmentation fault,报的结果Unix Signal SIGSEGV raised。SIGSEGV这个信号很烦人,说不好是为什么。但是我的程序又必须运行。硬着头皮去调,发现居然是一个一维数组越界,int a[6]我写到了a[6]导致出了这个错误。在windows上如果有VC6,只要debug模式下很容易找到问题,可是在linux下面画了我一天。这说明,出现segmentation fault至少需要考虑地址越界。
 
Linux下面又没有什么工具能在代码crash之前停下告诉我执行到源代码的哪一句?有的话告诉我,太折磨了!

2008年1月5日 杂

没事写点。
 
* 世界真小
2007年差不多也是这个时候,我收到了英国Bristol大学Jose博士的email,说他想帮我申请ORS奖学金,当他的学生。不过3个月后没申请到。阴错阳差,拿到了manchester大学的奖学金,到了曼大。见了曼大的导师Doug之后,他让我选题,并且告诉我他选我的原因是我想做的NoC是他的一个项目(我开始申请的不是他)。给了我3个题,其中我选了NoC的题目。呵呵,事情就发生了。这个项目的两个负责人一个是我导师,一个是Bristol的Jose,当时我就乐了。后来去Bristol开个小会,本想提一下,看看他记不记得,但是怕他忘了,没提,他也好像没看出来的样子。结果12月初,Jose发来一封邮件,问:我实在很好奇,你的名字和我上一年想收的一个学生的名字一样,你不是他吧?我默默地回答:世界很小,我就是。
 
* 谢谢
已经是第三次做法航了。22号从巴黎转机的时候有个事挺好玩的。我要等6个小时转机,要在机场买饭吃。到一个商店买水,付钱后,收银的法国小女孩对我说merci(french words: thanks)。我回答thank you。结果她看了看我,回了一句xiexie。我当时就愣了,整个买东西的过程中,她一直用法语,因为我也知道怎么做,也不用回答什么,只是用英文只言片语的回答,可突然听见了个中文。大概顿了1秒钟,才冲她笑着点头。呵呵,从出国到现在,这是我听到的第一声谢谢(从外国人的口中)。
 
* 北京的天空
回到北京,对于北京空气质量一下子没了信心。头两天多云,没什么风。结果市内就全天有雾,能见度也就几公里。在英国就是天气再差,也不会差到全天有雾的样子。我自就不得不怀疑到了10月,空气质量是否能有明显改观。
 
最后,我还要说,国人素质亟待提高。在法航上,某些中国人给我的感觉就是刘姥姥进大观园,疯狂找酒喝、晚上飞机上乱窜、聊天、一窝蜂上厕所、不系安全带、进了气流区不听劝告仍然到处乱跑等等,什么都有。算了,不说了。。。