回复 10# 镇水铁牛
会不会接收进程优先级太低，接到的信息来不及处理，全部堆在那里？
我找找发送端代码，贴上来
我好像找到问题了：
zmq_msg_init 应该是没有把以前在heap 里分配的指针free. 它只是在heap里再申请一块新的。每次循环调用这个函数时就申请一块新的。heap size自然就增加了。
那个代码对小message完全没问题。如果对大的message 就没有释放为content 指针分配的内存
本帖最后由 linuxfellow 于 2015-03-18 07:26 编辑
回复 10# 镇水铁牛
如果zmq是大的message,zmq_msg_close (&zmq) 有没有释放zmq.content所指的内存？ 我的理解是没有。zmq.content所指的内存没有释放，下次循环就不能用zmq_msg_init; 应该用zmq_msg_init_data.传一个free_mem函数进去释放zmq.content所拥有的内存
回复 14# linuxfellow
zmq_msg_close (&zmq)文档有点含糊。这个函数只是把zmq标志为“不再使用”，并没有马上回收。在我们的循环里，如果在zmq.content被释放前马上调用zmq_msg_init (&zmq)，这样就会有内存泄露。
在调用zmq_msg_init (&zmq)前要先检查并释放zmq.content
本帖最后由 linuxfellow 于 2015-03-18 12:58 编辑
会不会是个scope问题？ zmq_msg_close 释放内存，只有在变量zmq_msg不在其有效范围内时才真正释放内存。
如果把zmq_msg_t zmq_msg定义在while循环外，zmq_msg总是有效，message不会被真正地free
如果把zmq_msg_t zmq_msg定义在while循环里，zmq_msg出了有效范围，message就会被真正地free
while(1)
{
zmq_msg_t zmq_msg; //把变量定义到while-loop里面就不会泄露了；这样就会保证zmq_msg_close 正确工作？
zmq_msg_init (&zmq_msg);
len = zmq_msg_recv (&zmq_msg, rsock, 0);
if (len >= 0)
{
zmq_msg_send (&zmq_msg, ssock, 0);
}
zmq_msg_close (&zmq_msg);
}
好复杂的样子
本帖最后由 linuxfellow 于 2015-03-18 12:56 编辑
回复 17# 择天记
不复杂
3行代码。 问题是不是自己的代码，没法编译运行，只能想想各种可能。
以前对于应用层的代码，我只告诉他们你们的application有问题，让他们自己劳神去。
昨天坛里镇水铁牛老兄说帮我瞧瞧代码，我就向应用层的同事要代码，告诉他们问题能解决。既然话说出去了，就得解决问题。 从没用过zeromq, 临时翻书，想想可能的问题。
问题还是很有趣的。
但是下次决不干这种傻事了。
这是c++代码么？行为会跟scope有关系？好诡异……
回复 16# linuxfellow
回复 16# linuxfellow
在czmq的库中，发现他们是把上面的函数经过封装的，当时不确定，问题找到就好，不过基于czmq开发比较好，还有低版本的zmq是有缺陷的。