[大件事]gdb調(diào)試技術(shù)以及地址越界相關(guān)！·�。�

sublx

請教大家一個(gè)關(guān)于內(nèi)存地址突變的一個(gè)問題，是這樣的：
我有一個(gè)類一個(gè)方法是檢測條件狀態(tài)的。比如這樣：

1. void test::checkstatus()
   
2. {
   
3.         while(true)
   
4.         {
   
5.                 printf("this = %0x\n", this);
   
6.                 //其他代碼
   
7.                 if (this->need_process())
   
8.                 {
   
9.                         //process
   
10.                 }
    
11.                 //其他代碼
    
12. }
    
13. }
    
14. 
    
15. bool test::need_process()
    
16. {
    
17.         printf("this = %0x\n", this);
    
18.         //檢測過程
    
19. }

復(fù)制代碼

這個(gè)方法運(yùn)行在多線程環(huán)境中，而且這個(gè)方法也是create出來的一個(gè)線程執(zhí)行的（大家請忽略語法之類的錯(cuò)誤）

1. pthread_create(pid_t, NULL, test::checkstatus, NULL);

復(fù)制代碼

問題是：
test這個(gè)對象是在堆上new出來的， 、在運(yùn)行的過程中checkstatus,need_process 這兩個(gè)函數(shù)里面打印出來的this指針地址是一致的。

但是有時(shí)候程序在一直在正常得運(yùn)行（這里指兩個(gè)this打印一致,比如都是0x6EA8975），但是某個(gè)時(shí)刻checkstatus打印還是正常的（0x6EA8975），但是掉用need_process的時(shí)候
里面的打印是一個(gè)非法的地址值了，比如是（0x123),以至于need_process函數(shù)里面需要對對象成員進(jìn)行修改導(dǎo)致段錯(cuò)誤。
這時(shí)候，test這個(gè)對象是沒有析構(gòu)的（因?yàn)樵谖鰳?gòu)的最前面有打�。�。
我gdb進(jìn)去，
1 bt full，發(fā)現(xiàn)有一些值已經(jīng)是一些隨機(jī)值了（比如一個(gè)非常大的整數(shù)）。
2 直接print *this,直接提示 0x123這個(gè)地址不能訪問，
3 執(zhí)行up
4 print *this發(fā)現(xiàn)checkstatus這里面還是正常的，所有的變量什么的都是正常值。


我的疑問是，為什么在對象沒有被析構(gòu)的情況下，this指針發(fā)生了跳轉(zhuǎn)（正常情況這兩個(gè)打印this地址的值都是一樣的,而且這個(gè)段錯(cuò)誤不是必現(xiàn)的），
而且他的上一跳 執(zhí)行情況都是正常的 。

這個(gè)大概可能是什么情況呢？gdb之類的我不是很熟，所以想請教一下大家。
非常感謝。

linux_c_py_php

valgrind --tool=memcheck --log-file=xxx --leak-check=full ./your_program

關(guān)注xxx里的overlap, invalide 關(guān)鍵字。

另外， 看是否有棧溢出問題， 一般你找不到越界的時(shí)候可能是棧溢出了。

sublx

回復(fù) 2# linux_c_py_php

我不明白的是，這個(gè)對象是我在堆上申請的，調(diào)用這個(gè)函數(shù)之前什么都是正確的，但是接下來的調(diào)用，this指針已經(jīng)變?yōu)榉欠ǖ牧恕＿@個(gè)中間應(yīng)該沒有執(zhí)行任何代碼吧？因?yàn)槲抑苯?/gdb up 之后的 p *this 都是正常的。


   

sublx

回復(fù) 2# linux_c_py_php


    我的疑問是：比如：
  int *p = new int; //如果這里p的地址是 0xAEF1233（反正是一個(gè)合法的地址)
*p = 100；//這里 段錯(cuò)誤了 p的地址變成了 0x123(不是進(jìn)程空間的地址 ）

有什么原因 在我沒有做  delete p 這個(gè)動作  ，而 p的地址發(fā)生了跳變？

或者 ，我1樓的例子中 。我得到了一個(gè)core文件，我的操作步驟為(中間沒有插入任何步驟 )：
1、>bt full (在對象的這個(gè)函數(shù) need_process里  )
2、>print *this；(在對象的這個(gè)函數(shù) need_process里  )
       打印0x123不能訪問。
3、>up
4、>print *this (在對象的這個(gè)函數(shù) checkstatus里  )
    可以打印出 我new出來那個(gè)對象的所有正常的內(nèi)容。

是不是說明 1樓的進(jìn)程執(zhí)行順序是 checkstatus-->調(diào)用 need_process  中間沒有執(zhí)行這個(gè)進(jìn)程其他部分的指令？ 就像執(zhí)行順序?yàn)?
int *p = new int; *p = 100;那樣。

如果是這樣的話，連續(xù)執(zhí)行的2個(gè)指令，第一條的時(shí)候 this指針的地址還是合法的，為什么接下來的這一條就變成非法了？
在什么情況下會發(fā)生這樣的事情？
而且，每次this指針變?yōu)榉欠ǖ牡刂范际且荒Ｒ荒５?比如都是 ：0x123。

liuiang

建議你再看一下二樓的回復(fù)，你要確定明白二樓想讓你怎么去調(diào)試。

雖然并不一定是這個(gè)問題，但是，二樓說的是最大的可能。

sublx

那段是編譯選項(xiàng)？不太清楚怎么用。因?yàn)檫@個(gè)問題是偶爾出現(xiàn)的。

sublx

回復(fù) 5# liuiang


    關(guān)鍵是我在嵌入式系統(tǒng)上運(yùn)行的程序，能用那個(gè)工具嗎？整個(gè)系統(tǒng)RAM估計(jì)只有幾十M。

zylthinking

回復(fù) 7# sublx

不管是什么樣的奇技淫巧， 我覺得 pthread_create(pid_t, NULL, test::checkstatus, NULL); 這句將一個(gè)成員函數(shù)作為非成員函數(shù)作為 thread main, 是有點(diǎn)危險(xiǎn)的， 而且， 這個(gè)調(diào)用好歹
pthread_create(pid_t, NULL, test::checkstatus, &test); 才更合理吧， 就算這樣我也奇怪他居然能夠編譯過去不報(bào)錯(cuò)？


   

safedead

sublx 發(fā)表于 2013-01-31 00:03
回復(fù) 2# linux_c_py_php

我不明白的是，這個(gè)對象是我在堆上申請的，調(diào)用這個(gè)函數(shù)之前什么都是正確的，但 ...

對象是堆上申請的，對象的成員是個(gè)函數(shù)
你用了pthread_create去創(chuàng)建線程，線程的入口就是這個(gè)函數(shù)指針指向的地址，那么
函數(shù)里的任何自動變量都會用到棧，函數(shù)里的任何靜態(tài)變量都會線程間共享
函數(shù)說白了就是個(gè)地址，存儲這個(gè)地址的指針也許是堆上申請的，但是這個(gè)指針指向的內(nèi)存區(qū)域機(jī)器碼執(zhí)行可就未必是堆上的行為

sublx

回復(fù) 8# zylthinking


    程序里面不是那樣用的。我只是舉個(gè)例子說明那個(gè)函數(shù)是在一個(gè)單獨(dú)的線程里面運(yùn)行，
實(shí)際上是用 boost::thread 創(chuàng)建的線程 。我在powerpc上運(yùn)行的。