我正在创建一个应用程序,其中有几个进程通过提升消息队列进行通信。使用消息队列构造函数创建队列message_queue(open_or_create, name, max_num_msg, max_msg_size);
我对所有进程中的所有队列使用open_or_create,因为没有指定必须创建队列的顺序。 max_num_msg = 200
和max_msg_size = 500000
。
现在创建似乎都很好,但是在队列中发送消息一段时间后,由于读取访问冲突导致突然崩溃。做了一些调试,我转到了do_send
中message_queue.hpp
的定义,其中获取了一个用于编写消息的空消息头
//Insert the first free message in the priority queue
ipcdetail::msg_hdr_t<VoidPointer> &free_msg_hdr = p_hdr->queue_free_msg(priority);
//Sanity check, free msgs are always cleaned when received
BOOST_ASSERT(free_msg_hdr.priority == 0);
BOOST_ASSERT(free_msg_hdr.len == 0);
错误发生在free_msg_hdr.priority == 0
,因为free_msg_hdr
的地址没有指向可读的位置。
做了一点研究后发现,在创建队列时,
template<class VoidPointer>
inline message_queue_t<VoidPointer>::message_queue_t(open_or_create_t,
const char *name,
size_type max_num_msg,
size_type max_msg_size,
const permissions &perm)
//Create shared memory and execute functor atomically
: m_shmem(open_or_create,
name,
get_mem_size(max_msg_size, max_num_msg),
read_write,
static_cast<void*>(0),
//Prepare initialization functor
ipcdetail::msg_queue_initialization_func_t<VoidPointer>(max_num_msg, max_msg_size),
perm)
{}
创建的共享内存对象m_shmem
的大小太小,无法容纳200条大小为500000的消息。这就解释了为什么崩溃有点不可预测,因为仍然可以访问较小的内存部分,因此需要花费一些时间才能进入难以接近的部分。但是,我仍然不知道为什么会这样。查看函数get_mem_size(max_msg_size, max_num_msg)
,它返回正确的大小,但在创建后,大小更小。如果我然后重新创建相同的队列,它通常会得到正确的大小,我永远不会得到任何例外。如果有人知道为什么会发生这种情况,或者有关如何进一步调试此问题的建议,我将不胜感激。
我应该提一下,应用程序是用32位的Visual C ++编译的,并在Windows 10上运行.Windows共享内存实现是否会导致这样的问题?
当boost库创建消息队列时,它会请求一块共享内存来保存队列。我不确切知道它是如何工作的,也许它取决于操作系统的实现,但在Windows上,我可以在调试器中看到内存段的大小缓慢上升(连接调试器非常慢,这就是我注意到的原因)而获得的共享内存充满了零。在我们的例子中,在此期间附加到消息队列的其他进程显然获得了共享内存的当前大小。但是,内存开头的队列标头告诉它应该更大,因此第二个进程最终将访问未映射到其地址空间的内存范围中的消息,从而产生读取访问冲突。
在我们的例子中,确保其他进程只有在我们确定它被创建后才打开队列并因此我们的问题得到解决相对容易!