【问题标题】:RH Linux Mutex lock debuggingRH Linux Mutex锁调试
【发布时间】:2013-03-04 05:39:48
【问题描述】:

如果有人使用过 C++,多线程代码可以阐明互斥锁问题,我将不胜感激。它在 Red hat Linux 5.4 上运行。我们正在调试我没有编写的遗留代码。假设每秒执行非常高的调用,响应时间为 3-5 毫秒。我们在主应用程序中运行了大约 400 个线程。

我不喜欢这个应用程序的一点是在任何地方都使用智能指针(只要 SPtr 超出范围,就会调用互斥锁)。写这篇文章的人似乎对 SPtrs 上瘾了。很多函数都将 SPtr 作为参数。

应用程序可以正常运行几个小时,然后我们在锁定时突然得到互斥体 EINVAL(返回码 22)。我见过核心转储,它显示不同的堆栈跟踪,没有一个地方导致它。

您会推荐什么工具来调试它?这可能是由于内存或堆栈损坏(意味着与互斥锁无关的事情)而发生的吗?感谢您的宝贵时间。

【问题讨论】:

  • 试用 valgrind,使用 helmgrind 工具和默认工具。
  • 400 个线程在工作?还是在读取系统调用时被阻止?
  • Sam,应用程序的输入是每毫秒 1 次调用 (1000 cps)。调用被发送到另一个与数据库对话的应用程序 (tcp)。然后响应返回并发送回调用者。这是 VoIP 应用程序。因此,为了回答您的问题,线程正忙于处理传入信息或传出信息(未阻塞)。
  • 柔印,valgrind 和 hlgrind 看起来很有前途。我会试试看。现在他们甚至无法在所有线程都优雅退出的应用程序中进行体面的关闭。如果需要重新启动,他们只会终止应用程序。我正在输入代码以正确关闭(valgrind 需要它)。

标签: c++ linux multithreading mutex


【解决方案1】:

EINVAL 调用 pthread_mutex_lock 表示锁尚未正确初始化。这也可能意味着锁已被pthread_mutex_destroy 销毁。如果您有内存或堆栈损坏 - 如果您使用随机垃圾覆盖了互斥对象,或者您在调用其析构函数后尝试使用带有互斥对象的对象,则可能会发生上述任何一种情况。

如果你在 gdb 中打印一个互斥对象,你会看到如下内容:

$5 = {
  __data = {
    __lock = 0, 
    __count = 0, 
    __owner = 0, 
    __nusers = 0, 
    __kind = -1, 
    __spins = 0, 
    __list = {
      __prev = 0x0, 
      __next = 0x0
    }
  }, 
  __size = '\000' <repeats 16 times>"\377, \377\377\377", '\000' <repeats 19 times>, 
  __align = 0
}

在这种情况下,-1 的kind 字段意味着互斥体已被破坏。 0、1 或 2 的种类字段表示有效的互斥锁。其他字段应该都包含小整数或有效的指针。如果你看到随机的垃圾,这意味着互斥锁可能被某些东西破坏了。

【讨论】:

  • 克里斯,谢谢。我将使用 valgrind 来确保任何与内存相关的问题都出现并得到解决。如果互斥对象 __kind 字段的值不是 -1、0、1、2 时,gdb 可能可以设置为停止。这是我不知道的有趣信息。
猜你喜欢
  • 1970-01-01
  • 2010-12-26
  • 2019-05-06
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-02-02
  • 2012-10-24
  • 2012-03-27
相关资源
最近更新 更多