事件是酱紫的。
那天上午，轻轻松松实现了一个新性能的开发，本来打算着混到中午吃个饭，美美的午个觉，下午跑跑测试，摸摸鱼，划划水，欢快的一天就过来了。
正当我在为我的完满打算骄傲不已的时候，微信群闪过一条音讯，有人艾特我。
特么的！！！
这个时候！竟然有人艾特我！！！
过后我就不乐意了。指名道姓的艾特我，指定没坏事。

划开手机一看，果然，生产出事变了。而且看起来事件还比拟紧急重大。

我给大家简略形容一下事件的通过。
咱们（咳咳，请把"们"字去掉，说的就是你，别想甩锅）开发了一个能够采集宿主机硬件指标的这么一个性能。其中有一项是获取IPV6的地址，而后这个IPV6地址获取的时候出问题了，原本不应该获取fe80结尾的地址（fe80结尾的地址相似于IPV4的192.168,是局域网的地址，这个是应该pass掉的），却获取成了一串乌七八糟的数字。

过后的状况是这样的。客户提交了降级单，他们也怕出问题，就先降级了两千台设施，并打算当天早晨降级残余的两万多台。
而后到了快中午的时候，发现这两千台中，有那么一百台的样子，获取的地址不对。
如果嫌我说的啰嗦的话，请我师爷来翻译翻译。

简略来说，就是客户中午的时候发现了程序有问题，然而因为早晨要降级所有生产环境，所以下午必须给他们搞定。不能耽搁他们早晨的降级。此诚危急存亡之秋也。
什么状况啊？
劳资特么一脸懵逼啊！
没方法啊，谁让咱是吃这碗饭的呢？于是乎，简略拾掇一下，连午觉都不顾上了，背上我的蓝色小书包，坐上公交车，间接奔赴客户现场。

过后我心里是一点底都没有，这问题咱也没碰到过啊，于是脑中疾速过了一遍过后的代码逻辑，看看能不能找到能够甩锅的中央。嗯，测试！肯定是测试没测好！带着问题就上线了！
于是乎：

人家很明确的通知我，测试没有发现问题。
这就难堪了。公司环境没有发现问题，pit环境也没有发现问题（备注：该pit环境是客户提供的一套有限靠近生产环境的机器）。也就是说，这个问题仿佛是生产环境独有的。
这特么就扯了。。。
这都什么鬼啊？
没方法了，去现场看吧。

通过了简短而简单的客户园区入场手续后，终于来到了生产机房。客户找出两台有问题的机器，说，你调试吧！而后也不论我，忙他本人的工作去了。
生产的机器，如果玩过的大家都应该理解，客户不让做的事件千万别做，千万别想着删库跑路，而后坐船去新加坡，越南，柬埔寨。
特地是我过后拿到的是root权限。客户更是慎之又慎，就连重启程序都得通过他们批准。危险的命令想都不要想。
那还调试个鸡儿啊。

但这个时候我可不能怂啊，老夫一世英名是否保住，就看在此一举了。
首先我给客户强调，这个问题百年难得一遇，必定不是那么好解决的，今天下午就算能找到根因，回去还要批改代码，测试，早晨降级预计有点来不及。
打了这个预防针，客户也晓得问题辣手，就有心里筹备了。说，你先查起因吧，切实难解决的话今晚就暂缓降级，周五之前能搞定就行。
这样我就放心大胆的搞了。

先说一下咱们这个程序获取IPV6的逻辑。
咱们这个程序是用C语言开发的，为了反对跨平台，咱们引入了一个叫sigar的第三方库。这个sigar库是专门用来获取机器硬件指标的，而且对不同的平台操作系统都有实现。
在Linux下，获取IPV6的逻辑是读取/proc/net/if_net6的配置文件。这个文件的第一项就是IPV6的地址。
简略来说，获取ipv6的地址，就是读取文件中指定字符串的内容的实现。听起来剁么简略的事件。就这破逻辑，还能出啥问题？
sigar库里这段逻辑在 src/os/linux/linux_sigar.c 中的sigar_net_interface_ipv6_config_get函数中。当然咱们做了一些调整，最终的样子是这样的：

while (fscanf(fp, "%32s %02x %02x %02x %02x %16s\n",                  addr, &idx, &prefix, &scope, &flags, ifname) != EOF)    {        if (strEQ(name, ifname) && addr != strstr(addr, "fe80")) {            status = SIGAR_OK;            break;        }    }

说一下/proc/net/if_net6这个文件，这个文件里寄存的是接口和单播地址。其外部格局如下：
|addr(32位)|

addr（32位）if_index（个别2位十六进制数字）prefix（个别2位十六进制数字）scope（个别2位十六进制数字）flags（个别2位十六进制数字）ifname（16位）
ipv6地址接口ID前缀长度地址适用范围标记位网卡名称

这样一看，下面的代码解析，仿佛没有什么问题嘛。
但，等等，这都是什么鬼？

我嗅到了一丝立功的气味，尽管说不上哪里不对，但我感觉这里会有问题。第二位，也就是if_index，为啥呈现了这么多三位的？
一个三位的字符串，却用%02x，这是会出问题的呀。
可是，为什么会呈现3位的呢？

咱也不晓得啊。没方法，祭出百度吧！
然鹅，一上百度，是这个样子的：

家喻户晓，大天朝的技术文章，百分之八十被号称吃(C)屎(S)都(D)难(N)的某网站给劫持了，只有一搜寻，千篇一律的进去的都是该网站的链接，而且内容反复率之高，含金量之低，令人咋舌。
既然度娘不助我，我就只能寻求谷嫂的帮忙了。
可是！

完犊子了，这可咋办？
我突然想到我一个高中同学发小是做海内竞价的，本人守业当了老板，咱要不去试试白嫖一波？

嗯。。。弄起来还是挺麻烦的，但好歹是弄到了。
谷歌一游，大多数也只是通知你if_net6文件是啥含意的，没有通知我这个if_index到底应该有几位。
而后我在if.h头文件里发现了这个if_index的定义：

struct if_nameindex  {    unsigned int if_index;  /* 1, 2, ... */    char *if_name;      /* null terminated name: "eth0", ... */  };

int类型，实践上能够有8位啊，汗~
得，不论了。为了验证我这一猜测是对的，的确是if_index有三位导致的，我让测试的共事在pit环境找if_net6文件中有三位的测试，很快：

而后就是欢快的批改代码的过程了。咱也不论有的没的，搞什么位数啊，代码一旦hard code了，下次有变动还是得出问题，不如一把搞定：

while (fscanf(fp, "%s %s %s %s %s %s\n",                  addr, idx, prefix, scope, flags, ifname) != EOF)    {        if (strEQ(name, ifname) && addr != strstr(addr, "fe80")) {            status = SIGAR_OK;            break;        }    }

事实上，fscanf函数解决这种带固定宽度的解析时，如果字符串有三位，但只解析了两位，并不会把第三位抛弃，而是把第三位挤到了下一个域。
举个例子。

上图中第二条记录，if_index为321，依照上述代码逻辑解决时，会将32当做if_index,剩下的1当做prefix，40当做scope，20位flags，80为ifname， veth1ffa1a8原本是网卡名，它会将其认为是第二条的ipv6地址，导致前面的全副错位。
嗯。。。接下来就是把代码改好，从新公布补丁，让客户更新测试。
尽管过程是波折的，但后果是好的。

至此，故事整齐段落，惋惜了了我的午觉啊。