1. #include <stdio.h> 
2. int main(int argc, char*argv[]) 
3. {
4.     printf("Hello World!\n");
5.     return 0;
6. }

但是最近发现在 Linux i386 上面 load .so 以后覆盖 .so ，没有任何提示，正在运行的程序退出时侯则通常都会 segfault. 　和 sparc 很像了。

难道我记错了吗？

用 strace 看了一下，cp 打开目标文件的时侯，都是在 open 加 O_WRONLY|O_TRUNC|O_LARGEFILE 参数，但是打开正在使用的程序时，就会返回 ETXTBSY, 动态库直接成功。

怀疑 ld-linux.so 在处理 .so 时侯是不是有什么问题，于是 strace 了一下动态库的 load 过程, 发现就是 open O_RDONLY 以后mmap 加 MAP_DENYWRITE 参数，但是 man 了一下 mmap, man page 说这个 MAP_DENYWRITE 参数现在已经被忽略了，原因是会造成 denial of service （我不是很明白这个为啥会造成 DoS），看起来就是这个原因了，mmap 这样并不能阻挡其他程序改写 .so 文件。

但是为啥主程序就可以呢？还是得看 kernel 代码。发现 kernel 内部在加载主程序的时侯，是用的 do_mmap 函数来 mmap 文件的(binfmt_elf.c)，参数也有 MAP_DENYWRITE，因为是 kernel 内部函数，所以这个 MAP_DENYWRITE 实际是有效的，在 do_mmap_pg_off 函数(mmap.c)里面也确实可以看到对 MAP_DENYWRITE 参数的处理。

结论就是，Linux ，至少是现在的 Linux 下面无法像 Windows 一样，保护正在使用的 .so 文件，因此开发过程中如果要更新代码，请不要使用 cp 这么粗暴原始的替换方式，还是用 install 来做吧

使用方法很简单 , 编译出来这个 module 并复制到 lighttpd 的 lib 目录里面。

在 lighttpd.conf  的 server.modules 里面加上 mod_extforward

配置类似下面这样

extforward.forwarder = ("10.10.10.1" => "trust" , "192.168.1.2" => "trust" )

会自动跳过所有 trusted IP .

另外 由于 lighttpd 本身 plugin 结构的局限，加载 mod_extforward 需要在所有模块之后，否则其他都可以正常工作，但是 access log  打出来的对方地址还是 proxy 的。此外还有局限就是，$HTTP["REMOTEIP"] 的变量不会被 mod_extforward 影响，这个没有办法，对这个的判断先于所有的  plugin 加载。

 下载地址

Update: 修正了和条件语句冲突的情况。

　　fileio.i
%module fileio
　　%{
　　/* 这里放的是后面声明所需要的其他 header ，以及一些私有声明之类，会被 swig 原封抄到生成的代码里面去*/
　　#include <stdio.h>
　　%}
　　/* 这后面写需要生成包装代码的方法和对象声明，这个例子是C的，因此只有简单的函数声明，虽然 stdio.h 里面声明了很多函数和数据类型，但是我们想要包装的只有 fopen 和 fclose 两个函数 */

　　FILE *fopen(const char *filename, char *mode);
　　int fclose(FILE *fp);
这就是一个简单的 swig 输入文件, %module 是给这个扩展起名字，将作为这个扩展在脚本语言中的名字，如果在python里面，使用时候就要import fileio。

　　用 swig 处理 fileio.i 会得到一个 .c 或者 .cxx 文件，取决于 swig 是否加了 -c++ 参数。如果用 c++ 方式处理，那么 swig 生成代码会有所不同，比如分配内存会用　new 来作，但总的来说，区别不大。

　　[root@kangkang.org ~] swig -python -o fileio_wrap.c fileio.i

　　然后
　　[root@kangkang.org ~] gcc -shared -o _fileio.so -I/usr/include/python2.4 fileio_wrap.c

　　本例里面因为我们没有任何现有代码，封装的是libc里面已经有的 fopen 和 fclose ，因此只要单独编译包装代码 fileio_wrap.c 就可以了，如果是封装已有工程的代码，就需要将已有工程代码一起编译链接成动态库。

　　在执行 swig 的时候，swig 除了生成 fileio_wrap.c 包装代码之外，还会负责生成脚本语言端需要的声明代码，本例中它会生成 fileio.py，负责声明和加载 _fileio.so ，在 python 运行环境里面，只要 import fileio ，就可以自动载入 _fileio.so 。然后就可以使用 fileio.fopen 和 fileio.fclose 了。

　　这只是一个简单的例子，实际 swig 的功能远比这个例子来得强大，需要进一步了解的，可以读他的说明文档

在 /etc/my.cnf 里面的client 段加上

init_connect=”set names ‘gbk’”

更具体的可以参考 http://ria.richtechmedia.com/?p=313 这个链接，说得蛮清楚的。

智能狂拼 3 是一个很不错的输入法，虽然是一种整句输入法，单词输入能力一样很棒，响应速度比 MSPY2003 更是好了无数倍。官方出了一个 30M 的版本可以免费使用，实在非常厚道。

但是他有一个很恶心的 bug, 就是在某些程序里面经常崩溃，fterm 之类挂接了默认 SEH 的还好，MSN 之类就是用着用着就没掉了，实在不能忍，等了好久也不见补丁出来，只好自己动手搞之

用 ollydbg 启动 fterm , 在 fterm 里面用狂拼输入几下，就崩溃了，ollydbg 报告写入到一个地址不行

07CEB8AF C603 00 MOV BYTE PTR DS:[EBX],0

在 07CEB8AF 地方说不能写入到 EBX 指向的地方, ollydbg 里面显示这个 EBX 指向的位置居然是Unicode的 Windows\WinSxs 字串。这个是怎么弄出来的呢？先看看怎么才能跑到这里吧。

用 IDA 反编译 CSMPYEng.DLL （崩溃时候ollydbg停在这个 dll 里面），找到对应代码, IDA 标明代码引用的功能实在很棒，一下就看出来代码可能的流程了，如下，最后一行就是崩溃代码：

.text:1000B881 loc_1000B881: ; CODE XREF: sub_1000B7E0+7Dj
.text:1000B881 lea eax, [esp+2Ch+var_10+1]
.text:1000B885 lea ebx, [esp+2Ch+var_10+1]
.text:1000B889 push eax
.text:1000B88A call sub_100177B7
.text:1000B88F add esp, 4
.text:1000B892 test eax, eax
.text:1000B894 jnz short loc_1000B8A4
.text:1000B896
.text:1000B896 loc_1000B896: ; CODE XREF: sub_1000B7E0+C2j
.text:1000B896 inc ebx
.text:1000B897 push ebx
.text:1000B898 call sub_100177B7
.text:1000B89D add esp, 4
.text:1000B8A0 test eax, eax
.text:1000B8A2 jz short loc_1000B896
.text:1000B8A4
.text:1000B8A4 loc_1000B8A4: ; CODE XREF: sub_1000B7E0+B4j
.text:1000B8A4 mov cl, [ebx]
.text:1000B8A6 lea edx, [esp+2Ch+var_10]
.text:1000B8AA push edx
.text:1000B8AB mov byte ptr [esp+30h+arg_8], cl
.text:1000B8AF mov byte ptr [ebx], 0

这段代码并不难读，很清楚的看到这是一个循环，ebx 是某 char 指针 p，循环里面调用 call sub_100177B7 ，如果返回值是 0 , 则 p++ , 否则出来对 *p 进行一些操作。那么循环进入时候 p 是什么值呢？用 ollydbg 在 100b896 断点，随便按一个键让代码执行到断点，发现指向的就是我刚输入的字母。

现在问题就比较清楚了，多半是这个 sub_100177b7 在某些情况下面处理不正确，返回了0, 让 p++ 没完没了的跑下去，直到什么时候再次返回 1 , 这时候 p 都不知道跑到什么地方去了，这不崩就怪了。

之后的跟踪工作就不提了，总的来说很简单，发现问题在单独输入 i,u,v 的时候,　对于i/u/v字母之后的 null byte, 　该函数并没有判断，也返回 0, 导致指针越界很远。修正工作也比较简单，将 sub_100177b7 的入口 patch 跳转到别处，判断一下输入，如果是 null byte, 直接返回 1, 否则转原来入口。这个 dll 的函数是按照 16 字节对齐的，因此里面有很多空间可以塞二进制代码。。

这样智能狂拼3就可以正常使用了。

补记：我在水木上面发表这个补丁之后两天，官方就推出了修正补丁，真是 !@#$%^ 。不过也好，这里就不放修改之后的补丁文件了，需要的可以直接到官方网站上面去下载。

适中版本 http://www.tiansuo.com.cn/upload/kuangpin/CSMPYEng.zip

专业版本 http://www.tiansuo.com.cn/upload/kuangpin/CSPPYEng.zip

val = 5;
setsockopt(srv_socket->fd, SOL_TCP, TCP_DEFER_ACCEPT, &val, sizeof(val)) ;

里面 val 的单位是秒，

注意如果打开这个功能，kernel 在 val 秒之内还没有收到数据，不会继续唤醒进程，而是直接丢弃连接。

FreeBSD 有一个accept filter 的机制，不过看起来更牛一点, 可以注册自己的 handler 来处理连接。系统还提供了默认的 http filter, 接到完整的 http 请求了，再唤醒 accept 进程。

Linux 下面如果需要有东西可以内核态管理HTTP协议连接，那就是 tux 了。方汉是 tux 的爱好者。满街弄的都是 tux, 不过这个东西看起来非常需要人品，我跑了两次都造成了很多 oops 。还是算了。。

今天试验了一下果然不行。2000 之类不支持 winsxs 的系统都可以跑，xp 和 2k3 下面，都说没有正常设置，如果手动删掉 exe 里面的 manifest 的话，则是出个 assert, 说用不正常的方式 load dll

google 了一下，找到了某德国牛人的文章

http://blog.kalmbachnet.de/

Using the VC 2005 shared CRT/MFC (DLL) without a manifest is not supported!
If you build your app with VC2005 and you accidently have disabled the embedding of the manifest file (or deleted the separate appname.exe.manifest file), you will get an error on XP and later!

This has to do with the checking for a valid manifest of the EXE inside the CRT/MFC DLLs “DllEntry” (via a call to _check_manifest). If the OS supports manifests (or better Side-By-Side assemblies/DLLs) the CRTs´ DLL forces the check of the EXEs´ manifest. If there is no (valid) manifest, then the DLL refuses to load (returns 0) and therefor the EXE cannot be started. It might display the following error message (or similar):
R6034
An application has made an attempt to load the C runtime library incorrectly.
Please contact the application’s support team for more information.

But in the following cases the manifest checking inside the CRT-DLL is not done:

Pre-fusion OS (FindActCtxSectionStringW not found in kernel32.dll)
Loaded by instrumented-mscoree.dll (mscoree.dll and pgort80.dll is already loaded)
The path returned with GetModuleFileNameW of the DLL is longer than 8000 characters
The path to the DLL, returned by GetLongPathName is longer than 8000 characters

Microsoft 太变态了。faint, 于是按照该牛人的说法，注释掉 crt src 里面的 _check_manifest 调用， build 出来一个 msvcr80.dll , 和删掉 manifest 的 exe 配合使用就可以在任何系统上面使用了。

再次 fick microsoft.

事情的起因是这样的：

我想对某程序静态链接 libstdc++ ，但是动态链接　libc, 　因为这个程序用到了 dlopen , 而 dlopen 是无法静态链接的。于是我问如何在 configure.in 里面找到 libstdc++.a 的具体路径，好加在 LDADD 里面

首先是westline师弟给出的解决方案 gcc -print-file-name=libstdc++.a , man 了一下，原来 gcc 还提供了一坨类似的函数，用来把他知道的都告诉你。

接下来话题就变成了为啥需要静态链接 libstdc++ 了，我其实就是想避免 libstdc++.so.5 和 libstdc++.so.6 的问题
但是这时侯伟大的 kirbyzhou 爷现身了　

发信人: kirbyzhou (世界太小 梦想太大), 信区:
标 题: Re: 问个土问题
发信站: (Mon Dec 5 23:36:11 2005), 转信

主要是c++需要知道class的实现细节内容，主要是指对象的大小。
不然C++的.so接口定下来也不是什么难事。

【 在 COMMAN (　) 的大作中提到: 】
: 【 在 Kittyboy (Oyahoe) 的大作中提到: 】
: : ……
: : configure的时候定位出libstdc++.a的路径应该是可以的，makefile里面有那个路径，
就是configure出来那个gcc的lib吧。。
: : 不过静态libstdc++并且动态libc这个要求也特别了一点。。
: 这个是想尽量减少依赖性呀，FC2 上面是 libstdc++.so.5 , FC3 上面就是 libstdc++.s
o.6 了，太变态了，libc 倒是从 redhat ?.? 的时候开始已经是 libc.so.6 了。RH 9 开
始里面的名称也都是 GLIBC2.3 了

接下来大家开始讨论 Windows 下面把　MSVCR71.DLL 的符号都给 forward 到 MSVCRT.DLL ，以减少程序依赖性的问题。

kirby 爷还是一如既往的拍砖。

发信人: kirbyzhou (世界太小 梦想太大), 信区:
标 题: Re: 问个土问题
发信站: (Tue Dec 6 00:11:24 2005), 转信

【 在 boost (我是一棵无聊) 的大作中提到: 】
: 什么意思？缺的那些symbol？还是说名字一样过去也不去？
1.缺symbol，比如一些检查stack的内部小函数。
2.bootstrap不一样

: 【 在 COMMAN (　) 的大作中提到: 】
: : 但是 MSVCRT.dll 基本可以肯定不能支持 MSVCR71 的那些函数吧。我严重怀疑 forwar
d 过去了也是一调用就崩。

发信人: kirbyzhou (世界太小 梦想太大), 信区:
标 题: Re: 问个土问题
发信站: (Tue Dec 6 00:35:30 2005), 转信

1.exception/type_info及其子类的size不兼容问题
2.swprintf以及一系列和wchar_t*有关的东西
3.__set_buffer_overrun_handler等一系列
【 在 COMMAN (　) 的大作中提到: 】
: admire 爷，看来您已经研究过缺 symbol 的函数名了，给个列表吧。
: 【 在 kirbyzhou (世界太小 梦想太大) 的大作中提到: 】
: : 1.缺symbol，比如一些检查stack的内部小函数。
: : 2.bootstrap不一样

然后下来开始关于 manifest 的讨论。起因是大家开始讨论 VC8 的 msvcr80.dll 的安装问题，kirby 说这个一定要带 manifest, 否则根本不能用。我觉得不是这样的，不过我还没有做试验证明

发信人: COMMAN (　), 信区:
标 题: Re: 问个土问题
发信站: (Tue Dec 6 00:41:47 2005), 转信

嗯，manifest 是表明了你这个 dll 在什么样的 context 下面 load
然后 xp 支持一组 activatectx 之类函数，程序可以调用设定要用什么 context.
如果非常懒，可以给程序也写一个 manifest, 这样 xp 的 loader 会帮你做这个事情
两者加一起就可以自动动态挂接编译者想要的 dll 版本了。不会造成 dll 版本冲突。
assembly 同理。

所以我总觉得这个不是必须的，如果没有大不了 fallback 到 system32 下面去 load 嘛

【 在 boost (我是一棵无聊) 的大作中提到: 】
: 我土鳖地问一句，manifest是不是就是包了一个依赖的crt dll的assembly名字，
: 用来在winsxs目录下找dll？
: 【 在 COMMAN (　) 的大作中提到: 】
: : 可能是，我刷个牙回来还没有拍出来，不过我还是觉得manifest 不是必须的，跟 wins
xs 下面那些冲突就冲突了，基本造成问题的可能性微乎其微，只要 microsoft 这个 dll
的向下兼容性还能够保持就行。

本来话题发展到这里，已经跑题很远了，但是 zeel 爷出现了，并且给出了这个话题开始的最标准答案
为这个讨论划上了完美的句号。

发信人: zeel (我爱我老婆), 信区:
标 题: Re: 问个土问题
发信站: (Tue Dec 6 00:25:03 2005), 转信

发信人: Valentin Nechayev , 信区: Unix
标 题: Re: Linking with different static and dynamic library
发信站: Dark side of coredump (Tue Mar 11 20:15:23 2003)
转信站: SMTH!maily.cic.tsinghua.edu.cn!news.happynet.org!news.cn99.com!newsfeed
出 处: news.lucky.net

>>> Kenji Chan wrote:

KC> Here I’ve got a “program” which links to two library lib_a and lib_b
KC> when I use –static for g++, it links all library statically
KC> But how can I do this:
KC> program –> statically lib_a.a
KC> also –> dynamically lib_b.so
KC> What command should I type?

If your system uses GNU ld, you may try following:

gcc -o $prog $objs -Wl,-Bstatic -l_a -Wl,-Bdynamic -l_b -Wl,-Bdynamic

last -Wl,-Bdynamic is here to provide mode for system default libraries
(libc, etc.)

(If linker isn’t GNU ld, find details in linker manuals.)