C -方法根據gdb回傳非空指標，但分配給它的變數為空

我有一個問題，我從靜態鏈接庫呼叫一個方法，該方法回傳一個指向資料結構的指標。根據除錯器，回傳的值是非空的。但是在方法回傳并將值賦給區域變數后，該變數為空。

下面的螢屏錄制演示了這個問題。記錄在呼叫方法之前開始，然后步入該方法并退出。如您所見，該方法回傳一個指向地址 0x6920ae10 的指標，但隨后存盤在區域指標變數中的值為 0x0。

我在這里不知所措...我已經使用 C 很多年了，但我以前從未遇到過這樣的問題......我在這里錯過了一些愚蠢的東西嗎？什么可能導致這個問題？

我之前直接在執行代碼的機器上編譯了靜態鏈接庫（Impinj RFID Readers 的 LLRP），我也在同一臺機器上重新編譯了整個程式，所以我不認為這是二進制檔案之間的不匹配遠程機器上的代碼和 IDE 中的代碼。

相同的代碼以前確實可以作業，但現在它運行在不同的平臺上（在 Raspberry Pi 上而不是 Alix 板上，在 Raspbian 上而不是 Ubuntu 上）。

更新： 我今天一直在進一步調查這個問題，我發現問題發生在這里（稍微更改為影片中的代碼但問題是相同的）：

::LLRP::CReaderEventNotificationData *p_msg_ren_d = ((::LLRP::CREADER_EVENT_NOTIFICATION *) p_msg)->getReaderEventNotificationData();

if (p_msg_ren_d == NULL)
{
    delete p_connection;
    delete p_msg;
    this->_fail("Invalid response from reader (1).");
     return;
}

這是呼叫方法時的反匯編（我正在編譯-O0）：（我的評論，我認為正在發生的事情）

=> 0x001ee394 < 576>:   ldr r0, [r11, #-24] ; 0xffffffe8                    "Load address of p_msg into r0"
   0x001ee398 < 580>:   bl  0x1f0658 <LLRP::CREADER_EVENT_NOTIFICATION::getReaderEventNotificationData()> "call getReaderEventNotificationData"
   0x001ee39c < 584>:   str r0, [r11, #-28] ; 0xffffffe4                    "store r0 on the stack at sp-28"
   0x001ee3a0 < 588>:   ldr r3, [r11, #-28] ; 0xffffffe4                    "load sp-28 into r3"
   0x001ee3a4 < 592>:   cmp r3, #0                                          "check if rd is NULL"

Here is the c code and disassembly of the method that gets called (p_msg->getReaderEventNotificationData()):

inline CReaderEventNotificationData *
getReaderEventNotificationData (void)
{
    return m_pReaderEventNotificationData;
}

   0x001f0658 < 0>:     push    {r11}       ; (str r11, [sp, #-4]!) "save r11"
   0x001f065c < 4>:     add r11, sp, #0                             "save sp in r11"
   0x001f0660 < 8>:     sub sp, sp, #12                             "decrement sp by 12"
   0x001f0664 < 12>:    str r0, [r11, #-8]                          "store r0 on the stack at sp-8"
=> 0x001f0668 < 16>:    ldr r3, [r11, #-8]                          "load sp-8 into r3"
   0x001f066c < 20>:    ldr r3, [r3, #24]                           "load r3 24 into r3 THIS IS WRONG!"
                                                                    "m_pReaderEventNotificationData is at offset 28 not 24"
   0x001f0670 < 24>:    mov r0, r3                                  "move r3 into r0 as the return value"
   0x001f0674 < 28>:    add sp, r11, #0                             "restore sp"
   0x001f0678 < 32>:    pop {r11}       ; (ldr r11, [sp], #4)       "restore r11"
   0x001f067c < 36>:    bx  lr                                      "return"

If i take a look at the momory at the address p_msg, this is what it looks like:

0x69405de8: 0x002bcbf8  0x002b8774  0x00000000  0x69408200
0x69405df8: 0x69408200  0x5c5a5b1a  0x00000000  0x6940ed90
0x69405e08: 0x00000028  0x0000012d  0x694035f0  0x694007c8

So at offset 24, it's actually 0x00000000 and that's what returned by the method. But The correct value that should be returned is actually at offset 28 (0x6940ed90)

Is this a compiler problem? Or some 64 bit thing?

This is the compiler version btw: gcc version 8.3.0 (Raspbian 8.3.0-6 rpi1)

uj5u.com熱心網友回復：

什么可能導致這個問題？

最可能的原因是您已經使用優化編譯了代碼，并且感到困惑。程式是否繼續報告invalid response from reader，或者它實際上是否繼續到第 181 行。

如果是后者，請參閱此答案。

如果程式確實執行了第 179 行，那么很可能是您的編譯器錯誤編譯了您的程式（您需要反匯編代碼以確保）。

在這種情況下，嘗試不同的編譯器版本、禁用特定函式或檔案的優化、更改優化級別等可能會讓您解決編譯器錯誤。

更新：

該程式確實報告了閱讀器的無效回應，因此它實際上被呼叫了。我花了一個下午的時間再次調查這個問題，此時我相信這是一個編譯器錯誤。在反匯編中，我可以看到它試圖m_pReaderEventNotificationData 從物件地址 24 ( ldr r3, [r3, #24])加載 的值，但是如果我查看記憶體，在這個偏移量實際上是 0x000000。它應該回傳的實際值是偏移量#28 而不是#24。

這實際上是一個非常常見的問題，通常源于 ODR 違規或不完整的重建。

假設您有兩個目標檔案：foo.oand bar.o，并且還定義了

const int NUM_X = 6;
struct Bar {
  int m_x[NUM_X];
  void *m_p;
  void *Fn() { return m_p;}
};

上面給出，Fn()將回傳*(this 24)，這個偏移量將被編譯到兩個目標檔案中。

現在您NUM_X從 6更改為 7，并重建foo.o但不是 bar.o. Fn內bar.o將仍然回傳*(this 24)，但它應該回傳*(this 28)（假設32位二進制）。

如果struct Bar在foo.ccand bar.cc（違反 ODR）中定義不同，可能會發生類似的行為。

更新 2：

我從磁盤中洗掉了庫的所有痕跡并重新編譯了 .a 檔案并重新安裝了庫和頭檔案。我還嘗試在 lib 不存在時重新編譯程式并出現聯結器錯誤，所以它絕對沒有使用我不知道的另一個版本的 lib ......我還洗掉了程式的完整版本并完全重新編譯它......但它仍然是相同的行為......

您應該驗證所涉及的兩個檔案是否看到相同的CREADER_EVENT_NOTIFICATION. 最好捕獲預處理檔案并比較那里的定義（這是編譯器實際看到的）。請務必使用您用于構建庫和應用程式的確切編譯命令。

One sneaky way ODR violations can creep in is if the #defines in effect when building the library and the application are different. For example, consider this code:

#ifdef NUM_XX
const int NUM_X = NUM_XX;
#else
const int NUM_X = 6;
#endif

struct Bar {
  int m_x[NUM_X];
  void *m_p;
  void *Fn() { return m_p;}
};

Now compile foo.cc with -DNUM_XX=7 and bar.cc without it, and you've got an ODR violation.

標籤：c pointers null gdb remote-debugging

上一篇：使用memcpy復制地址的記憶體

下一篇：如何對齊在堆上分配的指標（使用malloc）？