騷年，千萬別偷懶啊！

大眾推薦

話說。。。。2年前開始寫的一個(gè)服務(wù)器程序，一年前上線，跑了一整年，沒有掛過，前段時(shí)間剛小得意了一下。。。

結(jié)果，3周前，悲劇了。。
在過去3周里，掛了8，9次�。。。。。�

由于是跑在公網(wǎng)上正處于服務(wù)期的，加上很久沒怎么看過那份代碼。。。再加上自己近來比較忙，也懶。。。。。種種原因。。。。
反正斷斷續(xù)續(xù)的跟了3，4天，根本不知道是怎么回事。。。。。
而且自己記得最近沒怎么改這份代碼。。。

從3天前開始，實(shí)在是無法容忍了，于是乎gdb,strace什么的都用上了，雖然coredump大致定位了位置并提示是訪問了非法內(nèi)存，
但仔細(xì)看了該部分的代碼還是沒有找到具體的問題。。。。

可以肯定的是，出現(xiàn)問題的哪行代碼是很久沒改過了。。。
反復(fù)閱讀了這部分代碼，實(shí)在是沒問題。。。而且這部分代碼跑了1整年了，都沒有CRASH過。。。

這不科學(xué)�。。。。�！

仔細(xì)回想，大概在1個(gè)多月前，曾經(jīng)嘗試優(yōu)化一下HASH TABLE。。。。
于是，看了一下這部分代碼，也對(duì)比了一下之前的版本。。。。還是沒有發(fā)現(xiàn)代碼有問題。。。。

不過aaaaa.c 有類似這樣的一個(gè)地方：
struct A* a (void)
{
#if XXX
      return aa();
#else
      return bb();
#endif
}

其中，之前代碼只有 aa(),其他函數(shù)也只是直接調(diào)用 aa();
而 bb()是為了測(cè)試某一樣?xùn)|西加而加的，
而為了這個(gè)測(cè)試，a()也是后來加的。

由于之前吃過一次虧，所以趕緊找aaaaa.h來看，果然是沒有聲明a(void)!!!!!

-----------------------------------------------------
背景交代完畢，

A.由于a()返回的是一個(gè)malloc()出來的內(nèi)存指針。
B.我沒有在頭文件中聲明函數(shù)的返回類型（一般不會(huì)出現(xiàn)這種不聲明返回類型的情況，除非是。。。有時(shí)候太HIGH了，根本就不記得了。。，而自己又不是每次都會(huì)清空編譯時(shí)候的WARNING）。
C.C返回的默認(rèn)指針，是只有32BIT的。前面的32BIT會(huì)自動(dòng)CUT掉。
D.跑的服務(wù)器是64BIT的。

于是乎，當(dāng)某個(gè)時(shí)刻malloc()出來的內(nèi)存地址，其前面的32BIT不全為0的時(shí)候，而系統(tǒng)已經(jīng)CUT掉了前面的32BIT，那么剩下了的地址就肯定不是我們想要的。。。。
或者說，在linux（UBUNTU AMD 64)中，調(diào)用隱式聲明的API，返回默認(rèn)是一個(gè)32位的INT，而接收這個(gè)返回值的時(shí)候，會(huì)轉(zhuǎn)換這個(gè)返回值為指針，并自動(dòng)補(bǔ)齊高32BIT的值
（貌似是，如果返回值的最高位是1，則全部補(bǔ)0XFFFFFFFF，如果返回值的最高位為0，則全部補(bǔ)0）

所以，當(dāng)返回的地址第31-63 BIT（不是第32BIT開始，而包括31）不全為0的時(shí)候，自動(dòng)補(bǔ)齊得出的地址，就肯定不對(duì)。。。這個(gè)時(shí)候去訪問，就掛了。。。

-----------------------------------------------------
告誡各位新人，以后寫代碼，千萬不要偷懶。。。
1.不可不聲明全局函數(shù)。特別地，當(dāng)返回值是一個(gè)指針的時(shí)候，+你跑的是64位的系統(tǒng)的時(shí)候。。。。。
2.不可放過編譯時(shí)候的任何一個(gè)warning.當(dāng)然，-Wall是必須的。

hellioncu

不看警告，自作孽不可活

folklore

B.我沒有在頭文件中聲明函數(shù)的返回類型（一般不會(huì)出現(xiàn)這種不聲明返回類型的情況，除非是。。。有時(shí)候太HIGH了，根本就不記得了。。，而自己又不是每次都會(huì)清空編譯時(shí)候的WARNING）。
<< Warning 一定要當(dāng)做錯(cuò)誤處理
C.C返回的默認(rèn)指針，是只有32BIT的。前面的32BIT會(huì)自動(dòng)CUT掉。
<< 很神奇， 還有這種編譯器（Intel 64Bit的話， 返回值應(yīng)當(dāng)在RAX中， 足夠64位， 64位的話， void *返回32位只能說是編譯器的Bug）

bruceteen

回復(fù) 3# folklore
我猜，他的意思是，對(duì)于C89，如果省略返回類型的聲明，則返回類型默認(rèn)為int類型。比如 main()，等同于 int main(...)。
而在他的平臺(tái)上，int只有32bits，而指針有64bits。

zsszss0000

公司一般會(huì)要求消除所有的編譯器告警信息，這個(gè)是編碼規(guī)范啊。
可是我也幾乎從不消除編譯器告警。

大眾推薦

C.C返回的默認(rèn)指針，是只有32BIT的。前面的32BIT會(huì)自動(dòng)CUT掉。
<< 很神奇， 還有這種編譯器（Intel 64Bit的話， 返回值應(yīng)當(dāng)在RAX中， 足夠64位， 64位的話， void *返回32位只能說是編譯器的Bug）


>>嚴(yán)格來說，應(yīng)該是 接受到的，比如說 char* p = aa();
我們看到的p 的值還是64BIT的，但是只有低位的32BIT是對(duì)的，高位的32BIT是錯(cuò)的。

個(gè)人理解，沒有深入探究。

回復(fù) 3# folklore


   

大眾推薦

恩，對(duì)。。。

回復(fù) 4# bruceteen


   

大眾推薦

有時(shí)候，午夜，四周很安靜，
喝了2口白酒或者其它。。。
在實(shí)現(xiàn)一個(gè)新功能什么的。。。。

反正，就是大腦很HIGH的時(shí)候。。。。
只管看結(jié)果。。根本就不會(huì)去看WARNING。。。。
一般而言，我會(huì)在2-4周左右集中clean up一下。。。。
。。。。嗯，反正這個(gè)不是好習(xí)慣。。

hellioncu 發(fā)表于 2014-12-03 08:16
不看警告，自作孽不可活

大眾推薦

騷年，這不是好習(xí)慣啊。。。。得改。。。

回復(fù) 5# zsszss0000


   

大眾推薦

FYI.
h   ttp://blogs.#/360apps/2013/03/19/%E5%B0%8F%E5%BF%83c%E8%AF%AD%E8%A8%80%E7%9A%84%E5%AE%9A%E4%B9%89%E4%B8%8E%E5%A3%B0%E6%98%8E/