如何找出使用 gdb 实例化对象的位置？
我正在调试一个应用程序，它在一个位置出现段错误，几乎不可能确定多个实例中的哪一个导致了段错误。
我想，如果我能够解析创建对象的位置，我就会知道哪个实例导致了问题并解决了错误。
为了能够检索此信息，gdb（或其他一些应用程序）当然必须覆盖默认的 malloc/new/new[] 实现，但用它来检测我的应用程序就可以了。
有人可能会说，我可以在出现段错误的行之前放置一个断点，然后从那里单步进入对象，但问题是，这是一个中央消息调度程序循环，它处理很多不同的消息，我无法设置断点条件来捕获行为不当的对象。
I'm debugging an application and it segfaults at a position where it is almost impossible to determine which of the many instances causes the segfault.
I figured that if I'm able to resolve the position at which the object is created, I will know which instance is causing the problem and resolve the bug.
To be able to retrieve this information, gdb (or some other application) would of course have to override the default malloc/new/new[] implementations, but instrumenting my application with this would be alright.
One could argue that I could just put a breakpoint on the line before the one that segfaults and step into the object from there, but the problem is that this is a central message dispatcher loop which handles a lot of different messages and I'm not able to set a breakpoint condition in such a way as to trap my misbehaving object.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
因此，在发生段错误时，您拥有该对象，但您不知道创建此类对象的许多代码片段中的哪一段创建了该对象，对吧？
我将检测所有这些对象创建位，并让它们将创建的每个对象的地址以及文件和行号记录到文件中（__LINE__ 和 __FILE__ 预定义宏可以帮助简化此操作）。
然后在调试器下运行应用程序，让它捕获段错误，并在日志中查找有问题的对象的地址，以找出它的创建位置。然后剥下一层洋葱。
So, at the point where the segfault occurs, you have the object, but you don't know which of many pieces of code that create such objects created it, right?
I'd instrument all of those object-creation bits and have them log the address of each object created to a file, along with the file and line number (the __LINE__ and __FILE__ pre-defined macros can help make this easy).
Then run the app under the debugger, let it trap the segfault and look the address of the offending object up in your log to find out where it was created. Then peel the next layer of the onion.
您是否尝试过使用内存调试库（例如 dmalloc）。其中许多已经是新仪器等，并记录了分配情况。不过，有些比其他更容易从 gdb 访问。
该产品具有内存调试功能，可以满足您的要求：http://www.allinea .com/index.php?page=48
Have you tried using a memory debugging library (e.g. dmalloc). Many of these already instrument new, etc. and records where an allocation is made. Some are easier to access from gdb than others though.
This product has a memory debugging feature that does what you want: http://www.allinea.com/index.php?page=48
当发生段错误时，我会首先尝试在 gdb 中使用 backtrace 命令。如果这不能让我很好地了解正在发生的事情，我接下来会尝试使用 valgrind 来检查是否发生任何内存泄漏。根据我的经验，这两个步骤通常足以在大多数常见情况下缩小范围并找到问题点。
问候。
I would first try using the backtrace command in gdb when the segfault occurs. If that does not give me a good clue about what is going on, I would next try to use valgrind to check if there are any memory leaks occurring. These two steps are usually sufficient, in my experience, to narrow down and find the problem spot in most of the usual cases.
Regards.