你們有沒(méi)有遇到過(guò)棧地址增長(zhǎng)的情況？

yuxh

今天有個(gè)程序core掉了，調(diào)試了一下，跟蹤臨時(shí)變量的地址，發(fā)現(xiàn)很奇怪的現(xiàn)象：
地址一開始遞減，跑到一個(gè)動(dòng)態(tài)庫(kù)so中，就變成遞增了，象這樣：
程序開始：30322d98
調(diào)用動(dòng)態(tài)庫(kù)前：30321db0
動(dòng)態(tài)庫(kù)中（分配臨時(shí)變量前）：30317238
動(dòng)態(tài)庫(kù)中（分配臨時(shí)變量后）：30321190

可以看出分配了大約40多k的臨時(shí)變量，但這些變量地址怎么是遞增的？增到一定程序，把原來(lái)的棧破壞掉了，程序core dump

環(huán)境是AIX 5
誰(shuí)遇到過(guò)沒(méi)有？幫忙解釋一下？

roster

對(duì)不起，我解釋不了。
我是來(lái)求學(xué)的。
24點(diǎn)的算法。
你原來(lái)的注釋看不太明白，你有更好的方法計(jì)算嗎？
你有空能發(fā)個(gè)注釋給我嗎？
cheesae@tom.com

先謝謝了！

yuxh

樓上的不要這樣啊~~~
那都是好久以前的程序了，我總得自己看一下再說(shuō)吧？

roster

呵呵，對(duì)不起！
等您看完，有空的時(shí)候，不忘給我發(fā)一個(gè)注釋。
謝謝了

albcamus

沒(méi)遇到過(guò)。共享庫(kù)的函數(shù)，其中的自動(dòng)變量也是在棧里，不該與普通函數(shù)的壓棧方向不一樣啊

Alligator27

LZ能否說(shuō)明一下, 幾個(gè)數(shù)值是怎么得到的.

這是32位PPC吧.

yuxh

1. #include <iostream>
   
2. using namespace std;
   
3. 
   
4. int main()
   
5. {
   
6.     char s[100];
   
7.     int  n[100];
   
8.     double d[100];
   
9. 
   
10.     sprintf(s, "%p", s);
    
11.     cout << s << endl;
    
12.     sprintf(s, "%p", n);
    
13.     cout << s << endl;
    
14.     sprintf(s, "%p", d);
    
15.     cout << s << endl;
    
16.     {
    
17.         char c;
    
18.         sprintf(s, "%p", &c);
    
19.         cout << s << endl;
    
20.     }
    
21. }

復(fù)制代碼

在AIX 5上用xlC_r編譯(g++類似)

2ff22100
2ff22168
2ff222f8
2ff22618

在HP-UX上用aCC編譯(g++類似)

77a70a10
77a70a74
77a70c08
77a70f28

在LINUX上

0xbfffe780
0xbfffe5f0
0xbfffe2d0
0xbfffe2cf

可以看出在AIX和HP上都是先把局部變量的空間先算出來(lái),然后從低到高分配
之前說(shuō)的溢出是因?yàn)橛玫膙isibroker線程有�？臻g限制(只有64K?)分配了過(guò)多的局部變量的原因,而與地址增長(zhǎng)無(wú)關(guān)

albcamus

aix真是個(gè)怪物，我半星期來(lái)忙得焦頭爛額的調(diào)試，竟然發(fā)現(xiàn)Sys V的IPC之前，ftok全給我返回-1 。 只好定義了個(gè)wrapper，自己返回一個(gè)key，問(wèn)題才解決了。 在yuxh大哥的帖子上搭車感慨下。

Alligator27

64K是有點(diǎn)小.

棧地址遞減是相對(duì)于stack frame之間吧, 同一stack frame里的臨時(shí)變量地址應(yīng)當(dāng)是compiler自由選擇的.

win_hate

如果系統(tǒng)實(shí)現(xiàn)了 alloc, 可以用它來(lái)測(cè)試棧的增長(zhǎng)方向。

[ 本帖最后由 win_hate 于 2005-12-15 00:14 編輯 ]