乙個棧溢位的BUG

// const

unsigned

len = 10 * (1u << 20);

char

data[len];

data[0] = 'a';

return 0;

}讀取資源限制(soft limit & hard limit)是由系統呼叫getrlimit完成的，getrlimit在核心中的入口是sys_getrlimit，**如下：

asmlinkage long

sys_getrlimit(unsigned
intresource, struct
rlimit
__user *rlim)
}

這個函式很簡單，就是把當前程序的某種資源限制讀出來，並複製到使用者空間，沒有發現什麼問題。

對棧的大小限制的檢查是在頁面異常(page fault)處理中完成的，從頁面異常入口page_fault開始，檢視呼叫序列page_fault > do_page_fault > expand_stack > acct_stack_growth，在函式acct_stack_growth中發現了對棧大小限制進行檢查的**，如下（省略了跟我們這個例子無關的**）：

static

intacct_stack_growth(struct
vm_area_struct * vma, unsigned
long
size, unsigned
long
grow)

static

intacct_stack_growth(struct
vm_area_struct * vma, unsigned
long
size, unsigned
long
grow)

一比較就可以發現官方核心**是直接比較size和棧的soft limit，而centos把這個比較放進了函式over_stack_limit裡，再來看函式over_stack_limit：

static

intover_stack_limit(unsigned
long
sz)

其中exec_stack_bias是乙個整型常量，定義如下：

#define

exec_stack_bias (2*1024*1024)

很顯然，centos把棧大小限制從soft limit往上提高了2mb，如果棧大小超過棧的soft limit+exec_stack_bias（在我們這個例子中為12mb）則說明棧溢位。到此真相大白，把上面的測試**修改一下（把陣列大小改為12mb），再一執行程序果然崩潰。

有時候接近問題的真相，但並沒有發現問題的全部，就這個問題來說，如果我不寫這篇文章，也就不會去寫上面那段測試**，就會想當然地認為在我的機器上棧的預設大小限制是10mb了。

乙個小程式的棧溢位

看下面 include int cp char p int main else return 0 在vs2008下面建個工程，我輸入 1234567 的時候輸出是 congralations 程式是正確的，但是當我輸入是 12345678 的時候，崩潰了，於是我把gs關了，結果輸出竟然也是 cong...

乙個小程式的棧溢位

看下面 include int cp char p int main else return 0 在vs2008下面建個工程，我輸入 1234567 的時候輸出是 congralations 程式是正確的，但是當我輸入是 12345678 的時候，崩潰了，於是我把gs關了，結果輸出竟然也是 cong...

微軟的乙個BUG

各位,我不知道我的這個發現屬不屬於微軟的乙個bug round 1.225,2 1.23 round 1.245,2 1.25 round 1.265,2 1.26 round 1.285,2 1.28 按照技術文章上說的,vb中round 函式屬於四捨五入函式,但實際執行當中,其實round 函式...