1

デバッグ方法がわからないという奇妙な問題が発生しています。

次の（C ++ 11）クラスメソッドがあります。

void RamCloud::write(uint32_t tableId, uint64_t id, const void* buf,
                     uint32_t length,
                     uint64_t* version, bool async)
{
    btree::node_cache& cache = btree::node_cache::instance(104857600);
        cache.write(tableId, id, buf, length);
    theCloud->write(tableId, id, buf, length, nullptr, version, async);
}

（コードが何をするかはあまり気にしないでください。ここではそれほど重要ではありません）。

ほとんどの場合、これは機能しますが、失敗する場合が1つあります。gdbを使用して最後の行で中断すると、次のことができます。

(gdb) p theCloud
$3 = (RAMCloud::RamCloud *) 0x7fbe14009e90
(gdb) p tableId
$5 = 3
(gdb) p id
$6 = 3
(gdb) p buf
$7 = (const void *) 0x7fbe253a22d0
(gdb) p length
$8 = 31496
(gdb) p version
$9 = (uint64_t *) 0x0
(gdb) p async
$10 = false
(gdb) s
#0  0x00007fbe220344aa in RAMCloud::RamCloud::write (this=0x0, tableId=0, id=0, buf=0x0, length=0, rejectRules=0x0, version=0x0, async=false) at /local/mpilman/ramcloudarch/ramcloud/src/RamCloud.cc:260
(gdb) p this
$11 = (RAMCloud::RamCloud * const) 0x0
(gdb) p tableId
$12 = 0
(gdb) p id
$13 = 0
(gdb) p buf
$14 = (const void *) 0x0
(gdb) p length
$15 = 0
(gdb) p rejectRules 
$16 = (const RAMCloud::RejectRules *) 0x0
(gdb) p version
$17 = (uint64_t *) 0x0
(gdb) p async
$18 = false

したがって、呼び出しの直前はすべて問題ないように見えますが、呼び出しの後、すべての引数（thisポインターを含む）はnullに切り替わります。続行しようとすると、もちろんセグメンテーション違反が発生します...

だから私の質問：ここで何が問題になるのでしょうか？呼び出し元は呼び出し先とは別のライブラリにありますが、これらのライブラリは静的にリンクされています（すべてが同じコンパイラでコンパイルされます）。

gccのバージョンは4.6.1です。誰かが私がデバッグを開始できるアイデアを持っていますか？

助けてくれてありがとう！

4

1 に答える 1

5

スタックが破壊されているようです。*nixのValgrindやWindowsのApplicationVerifierなどのツールを使用して、これらのメモリ関連の問題の原因を見つけることができます。

于 2011-11-17T18:01:32.777 に答える