我有一个指针 (**A
) 指向另一个指针 (*B
)。在程序中的某个地方,B
已损坏。但是,B
在存储到 *A
之前就已损坏。 B
并不总是位于同一地址(&B
并不总是相同)。但 B 总是被破坏为相同的值(B
总是相同的)。我知道这一点是因为我有一个损坏检测例程,它会查看要存储在 *A
上的下一个值,所以我只知道它已经损坏的点。
我想要的(当然)是找出B
在哪里被损坏。
我已经在 A
上尝试了一个 gdb 观察点,它会自动在 A
指向的 (*A
) 上生成一个观察点,当 B
首次存储在 *A
上时捕获 B
的希望,在它不再存储在 *A
上之前,变得损坏,然后存储回*A
。
watch A
commands
silent
watch *A
commands
silent
if *A == magicalcorruptedvalue
where
end
end
end
但问题是,使用硬件观察点时,*A
上存储了太多中间内容,因此我很快就用完了观察点。我还没有尝试过软件观察点,因为它们不能很好地与线程配合使用。
但是,我怀疑我不是第一个遇到这个问题的人。表达这个问题的更通用的方式可能是:当所有简单的技术都失败时,调试缓冲区溢出的技术是什么?
元参数:
在 Linux 上
这是一个多线程回调式应用程序。
最佳答案
我想出了两个答案,其中之一实际上对我有用。
使用正确的工具来完成工作。 gdb 用于调试程序流程。 valgrind似乎更适合调试内存/缓冲区错误。使用 valgrind 运行程序,我很快就发现了错误。
理论上,gdb 中实际上有一种方法可以做到这一点。实际上,只有当
*A
变化相对较少时,它才足够快。不是这个特定程序中更改的 10k+ 次。
这里是:
set $A = (void ***) &whateveritis
set $B = (void **) 0
set $WPN = 2
set $WP = 0
watch *$A
commands
silent
set $B = *$A
if $WP != 0
delete $WP
set $WP = 0
end
if $B != (void *) 0
watch *$B
commands
silent
if *$B == magicalcorruptedvalue
where
else
continue
end
end
set $WP = $WPN++
end
continue
end
这会在 A
上设置一个观察点,删除之前 *A
上存在的任何先前观察点(最终将设置为 B
) ,然后将监视设置为当前的*A
。 watch 总是在寻找 magiccorruptedvalue,尽管在我的例子中,当 B
存储在 *A
中时,它的任何变化都会是一个错误,所以我忽略了整个部分。
请注意,$WPN 是下一个断点的编号。请注意它由于临时隐式断点(例如通过 start
创建的断点)而发生变化。
这应该可行,但请注意,在我的例子中,程序陷入了困境,以至于它从未到达损坏的部分,因此 B
的观察点从未被触发。 YMMV。
回到现实世界,没有人用 gdb 做这么复杂的事情。这里的教训是:(1)了解现有的工具。 Valgrind 太棒了,我完全不确定任何 C 程序员,包括我自己,没有它是如何应对的。 (2) 仔细考虑问题领域及其与您尝试使用的工具的关系。如果该工具不适合,请使用或编写其他工具。不要让语言欺骗了您:仅仅因为您正在“调试”并不意味着您应该使用“调试器”来完成它。
关于c - 如何观察 gdb 中不断变化的指针的值?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18924855/