有什么可以导致异常16：＆QUOT;互斥：资源忙＆QUOT;到（使用Boost / BB10）被抛出？ [英] What can cause an exception 16: "mutex: Resource busy" to be thrown (using Boost / BB10)?
问题描述
我移植C语言编写的一个长期稳定的工作++库和Boost黑莓10设备之间的传输的库文件。该库编译和链接好，运行良好。不过，我一直遇到一个抛出的异常我的黑莓10设备上的1，2，或3个文件已被转移之后。在源$ C $ C捕捉异常作为一个boost ::系统:: SYSTEM_ERROR表明它是例外16，用文字互斥：资源忙。
I've ported a long-working stable library written in C++ and Boost to Blackberry 10. The library transfers files between devices. The library compiles and links well, and runs just fine. However, I consistently encounter a thrown exception on my Blackberry 10 device after 1, 2, or 3 files have been transferred. Catching the exception as a boost::system::system_error in the source code shows it is exception 16, with a text of "mutex: Resource busy".
下面是源$ C $ c其中发生异常：
Here is the source code where the exception occurs:
try
{
. . .
// Find DtpFunctionData for the operation ID, use it to invoke handling function
std::map<int, FunctionData>::iterator iter = _vecFunctionData.find (operationId);
if (iter == _vecDtpClientFunctionData.end ())
return EC_GENERAL_FAILURE;
HANDLINGFUNC_1 handlingFunc = (*iter).second._clientHandlingFunc;
POSTOPFUNC_1 postOpFunc = (*iter).second._clientPostOpFunc;
bool callPostOpOnSuccess = (*iter).second._callPostOpOnSuccess;
// Open a socket opposite the remote peer's TcpPortListener
/* Start: ----- EXCEPTION 16: "mutex: Resource busy" ----- */
boost::asio::io_service io_service;
/* End: ----- EXCEPTION 16: "mutex: Resource busy" ----- */
boost::asio::ip::tcp::socket socket (io_service);
. . .
}
catch (boost::system::system_error& err)
{
LOGLINE (("error", "Boost exception (%d / \"%s\") caught in HandleQueueOperation", err.code ().value(), err.what()));
return EC_EXCEPTION_CAUGHT;
}
跟踪日志行是：
18:37:04 ( 149077264) [error] Boost exception (16 / "mutex: Resource busy") caught in HandleQueueOperation
唯一的例外是开始和结束意见介于上述抛出，升压:: ASIO :: io_service对象的定义在哪里。我搜索计算器，谷歌等，为与互斥：资源忙什么，但都一无所获。我的code未在这一点上访问任何应用程序级的互斥体，所以我想互斥称为是升压相关之一。
The exception is thrown somewhere between the "start" and "end" comments above, where the boost::asio::io_service object is defined. I've searched StackOverflow, Google, etc. for anything related to "mutex: Resource busy" but have found nothing. My code is not accessing any app-level mutexes at this point, so I assume the mutex referred to is a Boost-related one.
有人能告诉我什么消息基本上意味着，为什么资源忙异常被抛出？是否有关于黑莓10的已知问题相关的例外呢？
Can someone tell me what the message basically means, and why the "resource busy" exception is being thrown? Is there a known issue on Blackberry 10 related to the exception?
在此先感谢！
推荐答案
调试很多同事后，终于解决了这个问题。
After much debugging a colleague finally solved the problem.
摘要
该异常被调用pthread_mutex_init（）后55-65的的boost ::互斥的构造函数调用，因为应用程序级的派生类对象，有一个boost ::互斥体作为成员变量，是被扔没有完全破坏，因为基类的析构函数被非虚。这导致的boost ::互斥-S的数量上升，直到互斥异常被抛出。当派生类的析构函数被调用正确的互斥例外不再被抛出。
The exception was being thrown by pthread_mutex_init () after 55-65 boost::mutex constructor invocations because an application-level derived class object, having a boost::mutex as a member variable, was not fully destructed because the base class destructor was non-virtual. This caused the number of boost::mutex-s to rise until the mutex exception was thrown. When the derived class's destructor was correctly invoked the mutex exceptions were no longer thrown.
沿途收集的相关/有趣的事实
（1）的早期理论提出，有在系统中过多的互斥和应用程序被超过允许的同步对象的最大数目一些未知的限制（尽管QNX文档明确指出这样的对象的数目为无限）。为了验证这一点，我们修改的的boost ::互斥的从类：
(1) An early theory was put forward that there were too many mutexes in the system and the application was exceeding some unknown restriction on the maximum number of synchronization objects allowed (although the QNX documentation clearly states the number of such objects is unlimited). To test this we modified the boost::mutex class from:
class mutex
{
private:
. . .
public:
mutex()
{
. . .
}
~mutex()
{
. . .
}
}
到
class mutex
{
private:
static int _nCount;
public:
mutex()
{
++_nCount;
. . .
}
~mutex()
{
. . .
--_nCount;
}
static int getCount ()
{
return _nCount;
}
. . .
}
请注意，获得了_nCount变量不同步（我们需要对这个互斥对象！），但调用调试的的boost ::互斥:: getCount将（）的从应用程序的功能给了我们信心，互斥体的数量是在异常的时间（平均55-65积极互斥）。
Note that access to the _nCount variable is not synchronized (we'd need a mutex object for this!), but calling the debugging boost::mutex::getCount() function from the application gave us the confidence that the number of mutexes was low at the time of the exception (55-65 active mutexes on average).
在最低水平监测对象的这种技术（例如，升压内互斥）加入静态接入功能在调试棘手的问题时要考虑的一个很好的工具。
This technique of monitoring an object at the lowest level (e.g., mutexes within Boost) by adding static access functions is a good tool to consider when debugging sticky problems.
（2）我们偶尔会收到ENOMEM异常，表示内存的问题（系统无法分配给创建互斥所需要的资源的）。
(2) We occasionally received an ENOMEM exception, indicating a memory problem ("the system cannot allocate the resources required to create the mutex").
（3）从三个月前在FreeBSD网站发布是非常类似于我们症状：
(3) A FreeBSD site posting from three months ago was remarkably similar to our symptoms:
我有，我似乎无法解决的麻烦。我的计划
创建和可重复破坏互斥（显然，使用它们的
之间）。围绕创建60锁，我总是ENOMEM。我有
释放内存，它的地段。所有锁得到适当的释放。
I'm having troubles that I seem unable to resolve. My programs creates and destroys mutexes repeatably (and, obviously, uses them in between). Around the 60th lock created, I always get ENOMEM. I have free memory, lots of it. All locks get released properly.
不幸的是，线程并没有为我们指出方向建设性
Unfortunately the thread did not point us in a constructive direction.
（4）取得了突破。使基类的析构函数虚拟固定的内存泄漏和解决互斥例外。
(4) The breakthrough came when careful studying of the application's code found a derived object whose base class destructor was non-virtual, thereby leaking some memory. Making the base class destructor virtual fixed the memory leak and solved the mutex exceptions.
（5）即使使基类的析构函数虚拟的，我们发现，使用QNX®Momentics工具套件为黑莓10编译时的派生类的析构函数没有被调用后。我们通过指定两个基地的和派生析构函数为虚黑客这个问题。直到那时派生的析构函数被调用。这可能表明在QNX编译器执行的C ++规范的错误，明确指出，虚拟岬传播到派生类（的工作草案，标准C ++编程语言（2012年），第250页，脚注9 ）。
(5) Even after making the base class's destructor virtual we found that the derived class's destructor was not being called when compiling for Blackberry 10 using the QNX® Momentics Tool Suite. We "hacked" this problem by specifying both the base and the derived destructors as virtual. Only then did the derived destructor get called. This may indicate an error in the QNX compiler's implementation of the C++ specification which states clearly that virtual-ness propagates to derived classes (Working Draft, Standard for Programming Language C++ (2012), page 250, footnote 9).
编辑：见<一href=\"http://stackoverflow.com/questions/35132860/my-qnx-bb10-c-application-crashes-a-simple-c-object-seems-to-be-corrupted/35132861#35132861\">this堆栈溢出后为QNX的下降对虚析构函数球的另一个例子。
See this Stack Overflow post for another example of QNX's dropping the ball regarding virtual destructors.
这篇关于有什么可以导致异常16：＆QUOT;互斥：资源忙＆QUOT;到（使用Boost / BB10）被抛出？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
