牛帖：

经济半小时：

mms://winmedia.cctv.com.cn/jingjibanxiaoshi/2007/06/jingjibanxiaoshi_300_20070628_6.wmv

呵呵，可能一切缘起于足球（哦，应该去掉“可能”两字）。不记得那年大眼加入《足球》，之前在高中最喜欢看的就是《足球》了。因为足球，喜欢上黄健翔的解说，喜欢大眼的评论（时间上来说，大眼应该排在黄健翔之后）。昨晚，在新浪的sports首页看了董路的blog，却在文末发现跟人掐架，于是“又”发现大眼的blog被从sports首页撤下。跑去大眼的blog上“果真”他们几个在掐架，呵呵，还真是见识少了，原来他们也可以“反目”的，原来也可以这样“掐”的。原来当某些利益冲突时，再“熟悉”甚至“熟知”的人们之间总会有些不和谐的声音，然而利益冲突无处不在（只是每个人都在维护中自己的圈子的平衡），一不小心也许就陷入了漩涡之中，这时大度与否往往最能体现在与朋友们的冲突之中，也最能影射关系是否到了铁的地步。掐之，则碎之；或掐之，化之。有些东西无法用所谓的具体利益来衡量的，有时一次“粗心”的“刮蹭”，带来的是一辈子无法弥补的遗憾！

记得从上大学起就很少有早睡的记录了（学校强制停电除外，没有办法嘛）。

现在终于扛不住了，想试执行11点开始休息的“决议”，看看效果如何。

昨天开会时知道“终于”要给应届employee发iPod了，今天从boss手上接过带有公司LOGO的iPod nano时心中“窃喜”－－不用买mp3了。iPod是去年公司在学校的宣讲会时许下的承诺：新入职的应届employee都会获得一个iPod。因为我没有参加宣讲会，所以也没有特别的期待，而参加过宣讲会的同学都很“惦记”它的，入职后一段时间没有动静，以为给“忘掉”了，呵呵，不过，还是发下来了。boss的说法是从我们这届开始，每届应届employee都会有礼物。哈哈，让老员工“眼红”了，而且貌似取消了应届的推荐奖。

如果时间
忘记了转
忘了带走什么
你会不会
至今停在说爱我的那天
然后在世界的一个角
有了一个我们的家
你说我的胸膛会让你感到暖

如果生命
没有遗憾
没有波澜
你会不会
永远没有说再见的一天
可能年少的心太柔软
经不起风经不起浪
若今天的我能回到昨天
我会向自己妥协

我再等一分钟
或许下一分钟
看到你闪躲的眼
我不会让伤心的泪挂满你的脸

我再等一分钟
或许下一分钟
能够感觉你也心痛
那一年我不会让离别成永远

我再等一分钟
或许下一分钟
看到你不舍的眼
我会用一个拥抱换取你的转身

我再等一分钟
或许下一分钟
如果你真的也心痛
我会告诉你我的胸膛依旧暖

 

ps：偶然听到，感觉不错

第一次参加Division Meeting，Boss从英国带回的信息归纳后有5条之多，meeting的主要目的

是给我们传递division的发展stragetics。里面提到了新的发展方向，新的产品和平台，我期间一直想提问的就是那么多新举措，究竟那一项是与我们关系“密切”的呢？呵呵，没想到，manager替我们把这个问题提出来了。答案也在意料之中，基本新产品新平台与中国无关，那些前沿技术，平台架构，甚至任何新的技术都不可能让中国来做的，起码可以预见的近期（应该是个不短的年头）是不现实的。我们只是de-defect，最多做做enhancement，在研发链中，我们处在一个很低的位置，其实，应该就是support or troubleshooting。个中原因很多，有政治因素，有技术的考量，有经济的考虑，从一位老员工的交流中了解到的其中一个原因：不放心让国内来搞新东西，有能力方面的考虑。会议期间，boss谈到员工内部transfer的问题，他说任何人如果想transfer的话，其实都是可以商量的，我想这个潜台词应该就是这里没有人不可以replace的，这样的工作，没有谁不可替代。作为这样一个division中的一员，你又会作何想？

 

其实，很久之前就知道这些事实：核心技术，甚至是关键技术，是很难转移到中国来做；国内的研发中心，大都做做本地化或者测试，技术支持（包括了enhancement类）。总的来说，附加值不高，可替换性大，说白点就是没啥技术含量。呵呵，这里可能有个例外，一个哥们说google的情况可能例外，有例外吗？if any, please let me know.thx. i am pleased to hear that.

 

btw:你会为了技术选择而跳槽吗？呵呵，算个survey吧

今天下午打篮球，“终于”把眼镜给打碎了，有6年之久的眼镜终于完成它的使命了。几年前就配好了的“新”眼镜终于可以出山了。代价就是划破4处：鼻子3处，脸上1处，不过，幸庆眼睛没有受伤。也许，该考虑隐形眼镜了。

昨天接到一个朋友的电话，讨论了一下M3UA以及它的组网方式。因为这两天在搞BAO培训，没有很好的进行深入讨论。呵呵，因为不做那个项目好长时间了，发现自己有些细节的东西已经不再像当初那么清楚地记得了，惭愧！有个事实就是当你脱离某项技术或者项目越久，越来越生疏是必然的，即使自己的写的代码，隔上一段时间再接手，都需要花点时间来回顾。

 

M3UA相关的细节可以参考rfc3332。M3UA在几种适配方式里是比较重要的一个，是唯一在3GPP的TS29.202中被定为用于R4及以后的核心网7号传输标准；并且在3GPP的TS25.412中也被采用，作为在R99及以后Iu-CS和Iu-PS接口RANAP的传输协议之一；TS29.205,TS29.232中，也被定义用来承载BICC和H.248。呵呵,follow 3GPP应该没错。

 

M3UA和M2PA使用应该比M2UA更加广泛一些，不过，在NGN的前期组网中，也有不少厂家的M2UA的解决方案出来。比较理想的一种方式应该是M3UA+M2PA方式混合组网，这样可以适用大规模组网。呵呵，这里不想展开来说（欢迎讨论），就简单的提一下M3UA方式下的2种组网方式：代理方式和转接方式。代理方式可以理解为从7号的视角来看IP侧只有一个信令点，SG和AS共用一个信令点，in-bound的信令由SG的路由映射来选择相应的AS/ASP，out-bound的消息同样由SG进行路由，关键词：共用；转接方式是SG和AS各自具备独立信令点，这样从7号的视角来看SG就像是STP，这样消息可以被路由到IP侧的不同信令点。这里需要补充的一点是：M3UA层只能进行一次转发，消息必须在peer端落地，这也是限制其大规模组网的一个因素吧。应用和分析协议和实现协议是两个不同的level，在实现过程中，往往会发现很多让人很“痛苦”，很“郁闷”的事，原因在于：协议只是制定规则，但并没有规定或者明确怎么做，而且往往协议制定时不太可能完全兼顾到实现层面的东西。呵呵，M3UA也同样如此，比如对于AS归属消息的判断等等。这样每个实现版本就有了协议无法统一的厂家自留地，开始时每个厂家的理解不一，可能会呈现的效率和起初的一些互通问题，但测试后，这些都会被在接口层面统一。

 

呵呵，该睡了，也许再过段时间，我的记忆又会更加模糊了，边学边丢！

什么是读越界？原因呢？

栈的大小？固定的？不固定的？怎么分配栈空间的？

如果你知道，可以离开这篇文章了，呵呵，不错，鼓励一个！

 

前两天Leo的一个minor defect--现象：CDR一个程序在HP-UX下运行没有问题，但在Linux下core dump。当Leo跟我说起这个问题时，我第一个反应就是字节序出了问题，80％的可能就在于此，于是，我没假思索就说，这个问题应该很easy，呵呵，因为我曾移植过2w多行的代码从Sun SPARC机器到Linux。当我过去Leo那边调试时，发现问题没有那么简单：1、代码很复杂，业务逻辑不熟，只能局部看看小部分代码；2、Leo说HP机器上运行没有问题（这时只能让我先假定它应该正确的，因为公司的产品之前基本就是运行在HP的机器上的）；3、memcpy的目的空间分配成功。这让我很纳闷，但还是从头分析：对于此类问题，最先考虑的是拷贝时长度字节序问题造成写越界；其次，再考虑内存分配成功否（分配失败的概率比长度弄错要小得多）；最后，只有考虑读越界的可能性了（其实，此时该考虑程序逻辑问题了，但因为之前的假定HP上没有问题）。

在Leo那边调试不方便，我只有第2天在自己的机子上用自己习惯的方式调试了，因为不同项目组，权限不同，编译就把我折腾的够呛，老出现缺胳膊少腿的，不过，最后非常规的搞定了。gdb调试时，发现几乎每次一进cbCc_unCompactUbit8函数里的memcpy时都segment fault。但目的地址空间分配没有问题，长度17862很可疑，但从源地址中解码来的长度，也没有问题（但从转换方式来看）。Leo说HP中也是该值。于是，1、直接写目的空间，成功，说明问题不在目的空间；2、直接跳过 cbCc_unCompactUbit8，并把按原来长度移动源指针，此时，程序按预想中core dump，不过，提供了2个信息：Memory Fault发生在cbCc_unCompactUbit16，并且提示Address 0xC0000002 out of bounds。呵呵，好家伙，脑中有点印象了，0xC0000000是Linux的栈底，因为16bit的缘故，在0xC0000002越界就合理了。直接原因就是读越界，我不熟悉此程序，但该程序run是有输入参数的：一个数据文件，因此，该问题转化为1、此数据文件有问题，导致解析长度内容时产生超大长度，那么找产生此数据的程序调试，对比相应的协议；2、数据文件没有问题，那就本程序的业务逻辑有问题（太难了，因为前面的处理都没有问题，说明前面的字段按协议解析是没有错误的）。呵呵，剩下的事我也就没管了，让Leo折腾去吧。

在第2天中午，微波炉热午饭前几分钟，我跟Leo说了我的看法，我说去查查起始源数组空间是不是太小了，长度过大，导致读越界，Leo就说数组不可能读越界，编译会通过，也不会core dump。呵呵，看来我就有必要写写这篇文章了，咋扯了那么远才切入正题呢？

 

其实，上面的问题，还是好些人不清楚的。很多程序员都是“高级”程序员，因为都用“高级语言”了，关心底层实现和内核的就少了，呵呵，题外话。

 

先说一下程序空间布局：

从低地址->高地址：|文本段|数据段|BSS|堆|~空洞(未映射的虚拟地址)~|栈|。

堆的分配可以不按顺序来，但总量一般会由系统用于堆的内存加可获得的虚拟内存大小决定（呵呵，硬盘有效空间说了算）。

栈从高地址向低地址端生长，一般在程序启动时就确定了栈的大小（这个是因不同程序而异，大小会有区别的），在各类系统中，一般栈底地址是固定的一个值，栈的大小在启动的时候，由内核根据参数在fork时会分配进程空间，而且该空间有效区域内操作才合法，否则，内核会结束该进程，报段错误（注意：进程在32位系统里拥有4G的虚拟空间，但实际上是不可能的，进程空间只能映射到一小段地址上，现在该地址基本上属于平坦空间分配）。

空间查看：在Linux上可以通过/proc文件系统来查看各进程的空间分配。不同的系统里，有不同的工具可以查看（pstack之类的，慢慢找吧）。

Linux的栈底为：0xC0000000

HP-UX 9000/785的栈底为：0x7fff3000

只要程序控制有问题（故意的除外），读越界也是可以core dump的，没有发生core dump是你的不幸，呵呵，“受伤”还不够深，经历的还不够多。只要地址进入内核保护区，或者溢出当前内存页所能表示的虚拟内存地址，必将Memory Fault，core dump不可避免。

下面是一个临时写的探测栈底的程序，只贴Linux版的，虽然ugly，有兴趣凑合看看吧。

 

#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <signal.h>
#include <string.h>

char* pAddress=NULL;
void handler(int);

int main(int argc,char** argv)
{

   char c;
   unsigned int i=0,flag,j,n;
   if(argc == 3)
   {
      n = atoi(argv[2]);
   }
   else
   {
      n = 1024;
   }

   char Array[n];
   flag = atoi(argv[1]);

   signal(SIGSEGV,handler);
   while(1)
   {
     j = (flag==0?-i++:i++);
     pAddress = &Array[j];
     c = Array[j];
   }

   return 0;
}

void handler(int sig)
{
   FILE* fp=fopen("stack.txt","a+");
   if(fp==NULL)
   {
     printf("My God,Good-bye\n");
     exit(0);
   }
   unsigned int address=0;
   fseek(fp,0L,SEEK_SET);
   fscanf(fp,"%lu",&address);

   #ifdef DEBUG
      printf("Line(%d)::address=0x%X(%lu)\n",__LINE__,address,address);
   #endif

   if(address==0)
   {
     fseek(fp,0L,SEEK_SET);
     fprintf(fp,"%lu",(unsigned int)pAddress);
     #ifdef DEBUG
        fseek(fp,0L,SEEK_SET);
        fscanf(fp,"%lu",&address);
        printf("Line(%d)::address=0x%X(%lu)\n",__LINE__,address,address);
     #endif
     fclose(fp);
   }
   else
   {
     address = abs((unsigned int)pAddress - address);
     printf("stack size up to (0x%Xbyte)(%luK)\n",address,address/1024);
     fclose(fp);
     remove("stack.txt");
   }
   printf("When coredump,the Address = %p,SIG = %d\n",pAddress,sig);
   exit(0);
}

 

ps:1、HP上之前的那个程序运行不报错是因为，测试HP的机器后发现，HP-UX 9000/785机器上居然要“很久很久”才到“栈底”，呵呵，在程序的源指针还没有触及保护区域（实现因系统而异），就结束这种操作了。这就是起先晃点我的原因。

    2、我访问的那台HP-UX 9000/785的cc居然不支持ANSI C，让我狂倒，可怜gg我努力忆记9年前的印象。