因為這次的經驗還不錯 雖然還沒找到問題 但是有人指點了方向之後
一整個感覺又有一條明燈出現.. 順便紀錄一下 不然老人家的記憶力 過目必忘實在很麻煩..
問題是發生在某些情況之下會hang在double exception, unhandled exception,
或是unaligned exception, 問題發生的很random,
但是可以有一些簡單的步驟可以reproduce,
不過在完全不熟析tool的情況之後, 這樣實在有點棘手.. :(
後來經過同事的提醒 .. 才看到stack似乎是有點異常, 也許不一定是這個問題
因為stack目前看起來 還夠用.. 但是size增加的卻有點怪..
因此先想辦法找到這個問題然後再回頭看看解決掉之後 是否還會有hang的問題..
首先這個是 一開始系統起來的sp的位置..
目前看起來距離stack_entry僅僅只有0x40 bytes左右
也就是.. _stack_entry = 0x4f6000; 而sp目前指在 0x4f5fa0, 所以似乎沒什麼問題..
扣掉幾個never return的function 起來後差不多就是這個size,
但是只要usb一起來之後, 大概就差不多等著掛點.. 這個是掛點後stack的內容~
可以看的出來stack的確異常的大.. 而且大的有點離譜.. 0x4f6000-0x4e6a30=0xf5d0了,
什麼東西要站這麼多空間? 目前不得而知..
但是想必應該跟usb還有那些debug function有關係
幾個接下來可能可以進行的方向..
1. dump stack出來看最後一次是什麼東西
2. 拿掉debug function看一下stack變化
3. 檢查_stack跟_stack_entry的差距 看是不是押到code了?
4. ... ? 以上幾件事情應該可以搞好幾天了 orz
===========================================================
已上是分隔線......
回頭順便注意了... 死掉的這個sp位置0x4e6a30, 發現這個位置應該就是code的位置,
看一下objdump可以發現 似乎壓到了memcpy
然後在看一下.. epc1的位置 落在 0x8e6a59 應該可以肯定
大概就是stack overflow掉了
因為再怎麼樣code跟stack應該都不會交叉在一起才對 ... o_0 orz
接下來應該可以很肯定的先做第一件事情dump stack順便看一下stack format
然後找一下哪些function一直被推到stack.. 在看看要怎麼解決吧..
呼呼.....
沒有留言:
張貼留言