博文

目前显示的是 三月, 2007的博文

在犹豫要不要打开HTT

重新编译内核,加上SMP选项,打开超线程支持?
有必要吗?
对性能是提升还是降低呢?

对代码进行批量清理

昨天一不小心,一个脚本把src目录下的每个文件后面都加了个\n
今天干脆写了个脚本,一方面清理多余的CVS目录,一方面用tr把所有的\n删除了。
唉,不爽的是。tr在Freebsd下总遇编码错误,而solaris 8 下一路顺畅。

请万分注意源文件的编码格式

在C/C++语言中,
在对源文件做预处理的时候,有两条基本原则:
1、凡是以//开头的为单行注释
2、凡是以\结尾的代表此行尚未结束于是预处理器在处理的时候会先按第二条规则,看每行的末尾的那个字符是不是"\",是的
话,就下一行接到本行。
然后把所有以//开头的注释和//的块注释去掉。但是存在一个问题,
对于big5中的汉字而言,其第一个字节的编码范围是0xA1 - 0xFE,第二个字节是0x40 -
0xFE。而'\'的ASCII码是0x5c.这就意味这,凡是以big5编码的文件,如果gcc没有正确的
认为它源文件的编码是big5,那么就可能出现因为单行注释末尾是汉字,而把下行的代码
吃掉的情况。这样是很危险的,但是gcc会给出一个警告:"warning: multi-line
comment In file"这样的问题在gbk中同样存在。
将下面的代码//你篭intmain(int argc,char* argv[]){ return0; } 以gbk的方式保存,并采用gcc 3.4编译。
无论是solaris 8还是freebsd 6.2,无论shell的locale的设置是zh_CN.GBK还是
zh_CN.UTF-8,所得到的错误都是相同的
$ gcc -c testgbk.cpp
testgbk.cpp:5: error: expected unqualified-id before "return"
testgbk.cpp:6: error: expected declaration before '}' tokeng++ 3.3下显示:
testgbk.cpp:3: error: parse error before `return'原因很简单,我把“好”字的GBK编码的后半个字节改成了'\'的编码,从而得到了"篭"字。
gcc发现'\'后面接着的就是'\n',故而把下一行"int main(int argc,char* argv[]){"也
当做注释一并删除掉了。按gcc 3.4的man页,gcc会根据shell的locale设置来猜测源文件的编码格式,否则它会把
其当作utf-8来处理。但是据我在F…

solaris又玩我

solaris8下没有strerror_r,也就罢了。我忍。
我今天用readdir_r,程序总是莫名奇妙的core dump.
一步步的追踪,while(1){ int ret=readdir\_r(srcdir,&entry,&result); if(result==NULL) break; if(ret!=0){ perror("遍历目录时失败"); break; } } 在进入到某个目录的时候,
执行readdir_r之前
(gdb) p *srcdir
$47 = {d_fd = 6, d_loc = 24, d_size = 264, d_buf = 0x80659d0 "\0043:"}
执行之后
(gdb) p *srcdir
$48 = {d_fd = 1853256494, d_loc = 2019914799, d_size = 1633824116, d_buf = 0x65\
73
}
(gdb) p ret
$49 = 0
(gdb) p result
$50 = (dirent *) 0x80471a0
很奇怪。尽管从返回值来看,readdir_r已经成功返回。(返回0,且 result指针也不是NULL)但是srcdir其内部的 d_buf字段已经被指向了一个无效的内存。
而尽管我用的是readdir_r,但是其实我的程序是单线程的。

灵异的一天

今天zyb试图用ftp登录174服务器访问我刚写完的代码。
结果发现不行。代码的目录是用符号链接指向另外一个硬盘的。
我们开始猜测是权限的问题。然后就不停的chmod。还是不行。
后来他准备把该符号链接删除重新建一次。
先用rm,被告知是个目录,不能删除。
于是他就使用了unlink。
唰的一下,该符号链接还在,但是所指向的目录已经消失了。
阿门…… 所有程序、代码、配置文件瞬间消失。
后来查系统的man页。发现unlink根本就不该出现这样的行为啊。它应该是删除符号链接。 (反正我很惧怕这个命令)
查proftped的文档,才知道proftpd就是不要支持符号链接,可能也是安全性原因吧。于是我就仿照另外一台机器,把DefaultRoot指向我所要访问的那个目录,算是勉强解决了这个问题。但是那个unlink的后果。。。。
后来奇异的事情更不断。
因为我写的程序是在Freebsd下写的,为了能在Solaris下也能跑。需要多定义一个宏变量,-DUSE_MT_SVC
否则每来一个新的rpc请求的时候都要重新打开一次数据库句柄。(Freebsd下rpc请求本来就是顺序执行的,所以很容易处理)
或许。。。或许是bdb的处理效率真的太高了,导致打开句柄的速度非常频繁,或许是我的句柄没有被即时释放,导致内存地址空间耗尽。。然后处理很多个请求后
Error opening database environment:not enough space
然后rpc server就core dump了。
好吧。
更神奇的事情出现了。
我此时本打算用gun的grep命令去查找日志文件已得知哪里出错了,去查找源代码以得知该修改哪里。
但是此时,只要一调用grep,那么grep就会core dump.
但是solaris自带的那个连-r都不支持的grep却可以!却可以正常使用!
查内存使用量:正常。
虚拟内存状态:正常!

gdb这般死法

今天人品好到了极点。
一开测试程序,跑上半秒,rpcserver就死掉,core dump.
每次用gdb -c core打开core,结果都是gdb core dump了。
my god~
新装的gdb啊!

推广Unix计划

推广Unix计划
简介:
义务帮助北京愿意使用、学习 Unix操作系统的学生、同事、朋友安装Unix类操作
系统,并在周末提供免费的技术支持服务。
你只需要在你的硬盘上提供一定量的空闲空间即可。它不会影响到你现有的应用。
不会损坏你现有的数据,也不会使你机器变慢。(我不知道你还担心什么,有什么
要担心的话就发信问我吧)
缘由:
我在中关村一家互联网公司从事技术工作,所以在电脑软件知识上相比而言要丰富
些。今天是周末,我和几个朋友外出游玩回来的时候,谈到IT业的一些事情,谈到
了一些电脑的使用技巧,我向他们讲述一些我的电脑使用经验,然后我说我用的不
是Windows操作系统,然后讲述了一些我所正在使用的操作系统(Freebsd)的好处。
然后就有朋友表示很感兴趣,想自己尝试一下这种独特的操作系统。
其实我一直也活跃在国内的Unix技术社区,也很想、也一直 在为其做一些力所能
及的贡献。我觉得本计划是一个不错的方式。所以立即回来写了这份文档。
为什么向你推荐Unix类操作系统:
0、它因你而存在
作为一名教徒,我的观点是,神因众人的信仰而存在;再而是神,让我有了信仰。
所以我感谢众人,感谢神。
而作为一名Unix类操作系统的用户,我的观点是,因为有用户,所以才有人去继续
开发它。所以它才有了自己的社区,才有很多人支持它,它才得以越来越成熟,越
来越先进。
而你的加入,就是向它的生命树上又添了重要的一笔。因为它必须能收到各行各
业、各国人民的反馈,才能发展的更完善、更好。
1、独特。
如果你追求一些与众不同,或是如果你想学习一些新知识,或是如果你想了解一些
刚被公开的核心的技术机密,或是如果你敢于创新并愿意不断的尝试新事物,那么
它很适合你。它可以按你的需求自由定制,为你量身打造。
2、免费。
Unix不是免费的,Linux也不尽是。但是我向你推荐的是免费的产品。
免费的产品和收费的产品差别不在于质量,而在于售后服务。免费的产品没有售后
服务,所以才有了很多我这样的志愿者去维护它。
3、专业。
很抱歉的是,Unix类操作系统还没有做到傻瓜化。
如果你是学生,你能学习到很多非常有用、非常专业的知识。
如果你是普通用户(对电脑技术不感兴趣),你能使用到世界一流的操作系统,享
受非常专业的软件服务。让蓝屏、莫名其妙的死机、天天杀毒 这些繁琐的烦恼统
统见鬼去吧。
另外特别指明,它并适合所有人。为了舒坦的享受它所带来的服务,而不是天天陷
入一大堆英文的技…

今天去清华蹭了顿饭

在丁香园
比较不厚道的一点是校外的人要比校內的人多掏11%的钱.
谴责一下

gdb狂死,无法忍受

一看版本是6.0
freebsd 6.2下是6.1
最新的release是6.6,去年底发布的
正在升级中

tcsh-6.15发布了

下载地址 ftp://ftp.astron.com/pub/tcsh/tcsh-6.15.00.tar.gz嗯,这是我最喜欢的shell

我现在越来越多的在用solaris了

我现在越来越多的在用solaris了,说说我的感受
1、solaris对中文的支持比Freebsd好。其实这个所谓的好不好没有明显的差别。主要是solaris对系统的基本部分的英文提示的出错信息都汉化成了中文。包括perror的输出。虽说作用不大,不过有胜于无
2、solaris对线程的支持比Freebsd好。
我觉得这个几乎是不需要争辩的了。
3、solaris的很多系统基本的库非常棒。
要列举的两个就是libm和sun rpc.
sun rpc是sun开发的,所以它在solaris上当然跑的很好。Freebsd下的sun rpc是较老的版本 (非常老)
Freebsd的libm库也是用的solaris的。
4、solaris的包的安装和使用没有Freebsd方便,包没有Freebsd多。
solaris下的包大部分都是二进制方式发布,所以对于系统的基本库的依赖很严重。经常依赖于系统的xxx补丁。对于从来不打补丁的管理员来说(这样的管理员太多了),简直就是。。简直不用考虑了(至少不用考虑CSW了,一个都装不上)。
包的数量也没有Freebsd多
5、solaris的GUI环境有很多特有的东西,需要一段时间去适应。
例如我从来没有用过CDE,看到solaris那个特有的输入法,xtt,也诧异了好一阵子。
6、solaris的Sun workshop很棒。
毫无疑问,这个东西比什么kdevelop用起来舒服多了。不过,它依赖的是sun的cc,这就意味着我得弃gcc不用,为我的代码添加更多的ifdef ...else...endif以保持可移植性。

下载solaris 8中

今天打电话找系统部的人借盘他们居然说没有,说什么我们好像没有这个操作系统的授权,etc.
算了,从sun的下载站的一个极隐蔽的角落里面找到了solaris8的下载链接。出乎意料的,下载速度居然徘徊在1.3M - 200k之间。真快~!

solaris 8下居然找不到ldconfig了

总是报告找不到xxx库。迫于无奈,编译的时候加-R,运行的时候设置LD_LIBRARY_PATH
后来发现其实ldconfig -m dir即可。
不过这是Freebsd/Linux下的命令。Freebsd下的ldconfig还是从sunOS 4.0中移植来的呢。
不过,solaris 8下找不到ldconfig了。取而代之的是crle
不带参数的运行crle显示当前的配置。
用crle -u -l dir把新目录加入进去

new week

一上班就忙的要死。my god~

最近灵异事件不断

mksh: Fatal error: Error reading `Makefile': Bad file number
Segmentation fault (core dumped)
我不就是执行个make,哪来这么多……狗屎
make被core dump了

qq又上不去了

QQ: Try extract GB msg: 您的号码暂时不能使用低版本的QQ,请到:http://im.qq.com/下载安装最新版的QQ,感谢您对QQ的支持和使用

写错一个括号害得gcc吃掉3G多内存

本来应该是constchar* test_data[] = { "", "./test.lock", "/tmp/test.lock", "你好", "a你好", }; test->add(BOOST_PARAM_TEST_CASE(&utf8len,(constchar**)test_data, (constchar**)test_data+sizeof(test_data)/sizeof(constchar*))); boost::unit_test::framework::run(test); } 结果写成了constchar* test_data[] = { "", "./test.lock", "/tmp/test.lock", "你好", "a你好", test->add(BOOST_PARAM_TEST_CASE(&utf8len,(constchar**)test_data, (constchar**)test_data+sizeof(test_data)/sizeof(constchar*))); boost::unit_test::framework::run(test); }; } 然后gcc吃掉3G多内存后,虚拟内存耗尽。系统 巨慢若是在Freebsd下,必然被kill了

无奈

今天把一个程序从Freebsd传到solaris下测试
在autoreconf的时候出现了问题
$ autoreconf -fv
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/local/bin/autoconf --force
configure.ac:24: error: possibly undefined macro: AC_PROG_LIBTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/local/bin/autoconf failed with exit status: 1
但是千真万确我的configure.ac中有AC_PROG_LIBTOOL,而且在Freebsd下用autoreconf一切都正常。
找了一个多小时,后来发现……原来我没装libtool

让人无奈的PGP Desktop 9

今天一个同事让我把我的pgp的public key发给她,因为她有一些重要的东西要加密后通过邮件发送给我。没有想到的是,我发给她后,她看了下开头的注释,提醒我检查我的pgp是不是9.0以上版本。如果不是的话,将有可能无法正确的解密。我想了想,无所谓吧?我用的是seahorse这种很傻瓜化的软件,但是采用的标准和算法都是统一的啊,1024位的DSA,嗯……我让她先给我发封测试邮件看看。结果是,解密失败。Could not parse S/MIME message
gpg: ASCII 封装头:Version: PGP Desktop 9.0.1 (Build 2185) - not licensed for commercial use:
gpg: 无效的 ASCII 封装头:www.pgp.com
gpg: 跳过无效的 64 进制字符 2e
gpg: 跳过无效的 64 进制字符 2e
gpg: CRC 错误:b6fdba - 7cbf96
gpg: packet(3) with unknown version 41?? 问题出在哪里了呢?后来我终于发现,我们公司大部分人使用的都是windows下的未付费版的PGP Desktop 9。它会在VERSION一栏长长的写明你是没掏钱的用户。-----BEGIN PGP MESSAGE-----
Version: PGP Desktop 9.0.1 (Build 2185) - not licensed for commercial use:
www.pgp.com正文信息
-----END PGP MESSAGE-----不幸的是, "Version: PGP Desktop 9.0.1 (Build 2185) - not licensed for commercial use:www.pgp.com"这一行文字的长度大于了78个字符(谁叫你不掏钱呢)。而按照rfc2822的标准,邮件正文中一行的长度不应该(should not)超过80个字符(包括回车换行字符在内),也不能(must not)超过1000个字符(包括回车换行字符在内)。邮件客户端就对这行"超长 "的语句做了折行处理。可惜这样处理过后,文本的格式就乱了。 www.pgp.com成了单独的、无法识别的一行。这导致后面的信息在处理的…

pthread库编译链接起来真麻烦

Freebsd下是编译要加 -pthread,链接的时候用-lpthread或者-lthr或者-lc_rsolaris下是编译的时候加-pthreads (多个s)其他的系统,一般是在链接的时候加 -lpthread不过Freebsd的好处是,乱写也无所谓,只要别加s就是了

发现autoreconf261的一个bug

我曾给automake110提过一个patch.
今天又发现一个,autoreconf261不能顺利的使用。
解决办法是:
修改autoreconf261的111行和112行:
原来为my$automake = $ENV{'AUTOMAKE'} || 'automake'; my$aclocal = $ENV{'ACLOCAL'} || 'aclocal'; 应修改为my$automake = $ENV{'AUTOMAKE'} || 'automake110'; my$aclocal = $ENV{'ACLOCAL'} || 'aclocal110'; 不修改也行,但是要设置ACLOCAL和AUTOMAKE两个环境变量。

freebsd终究还是不支持pthread_mutexattr_setpshared

今天调程序调的郁闷,先是查mmap的sync方式。后来发现命令行的fsync居然和系统调用的fsync有不同的效果,前者对NOSYNC的mmap无效。
后来拿了ACE的代码做测试,不是core dump就是显示Invalid argument
后来终于src/lib/libpthread中找到了这两个函数的实现int _pthread_mutexattr_getpshared(const pthread_mutexattr_t *attr, int *pshared) { if (attr == NULL || *attr == NULL) return (EINVAL); pshared = PTHREAD_PROCESS_PRIVATE; return (0); } int _pthread_mutexattr_setpshared(pthread_mutexattr_t *attr, int pshared) { if (attr == NULL || *attr == NULL) return (EINVAL); if (pshared != PTHREAD_PROCESS_PRIVATE) return (EINVAL); return (0); } 压根儿就只允许PTHREAD_PROCESS_PRIVATE的方式映射。
一会儿去solaris 9上面测试下。
教训:没有文档的函数不要用。

键盘坏了

昨天把显示器搬了过来,开机,发现POST过后都已经正常启动了,主机却莫名其妙的不停的短响。后来发现是键盘坏了,某个键被粘住了,所以导致键盘缓存区满,主机箱报警。
反正也用了3年多了,于是就被我拿来当灯绳了~~~可怜我。。。罗技的键盘啊!!!
p.s.要是能找到个小螺丝刀我就不买新键盘了