一个ACE中getq()时候产生的问题

wishel

原帖由 slugzoe 于 2009-11-25 23:42 发表
这里想问个问题，handle_output()和handle_timeout()是同一个线程还是不同的线程呢？

加个debug语句就行了，%t打印当前线程id

最近在看poractor的timer实现，在poractor中即使单线程跑event loop，ACE也会再单独开一个线程来跑timer queue的。
reactor的可以看看具体代码。

slugzoe

wishel的话给了我很大启示,昨天其实我在想是不是hanle_timeout产生了影响,所以我设置了临界区,结果还是有错,后来怕其他影响吧所有timeout里面的代码都删除了还是一样的错,所以我在想可能的确是message拼接时候出错了,现在正在检查message的拼接

slugzoe

原帖由 modern 于 2009-11-26 09:18 发表
看你Reactor使用的什么实现，
如果使用Select_Reactor是单线程的运行的，不需要线程保护机制。
如果使用线程池运行Reactor，比如TP_Reactor
同一对象的handle_output与handle_timeout会同时在不同的线程里被调用。 ...

没有用线程池，从call stack看应该是select_reactor，也检查了拼接，还是没问题，囧死了，好郁闷

slugzoe

另外还有个很奇特的现象是，在codeblock中debug的时候不会有问题，在命令行和gdb命令行中就会，真是晕

winston

多线程、网络代码，有一定的不可调试性~测不准原理。
因为你调试他了，就干扰了他的正常运行和调度，就会导致其它问题。所以，要用心想想办法。

slugzoe

恩,其实我没有设置断点,只是在codeblock里面跑,就不会出错...

wishel

运行到那一行发生段错误原因肯定是非法指针。
如果确定是拼接没问题，就再查查这个指针是否被delete过
可以加一些debug代码，把这个指针的值打印出来。看看是否是先前alloc的合法指针，中间有没有被delete过或者重新赋值指向未知地址。

wishel

原帖由 slugzoe 于 2009-11-27 15:22 发表
恩,其实我没有设置断点,只是在codeblock里面跑,就不会出错...

问题重现需要有条件的话，只有改ace源码，在出问题的地方打印想知道的信息，这样不必依赖调试环境重现问题。

modern

ACE_Message_Queue是ACE开发者用得最多的基础类，应该本身不会有太致命的漏洞。
建议楼主不要将问题复杂化，修改源代码重编ACE对于初学者不是一个快速解决问题的办法，
一般类似的问题，多是用法上的错误导致的。
另外尽管楼主提供了错误处的堆栈与代码，但是尚不足以定位问题，
希望能将GateWay_Service的全貌提供一下，以及运行Reactor的事件循环的使用方式等。

wishel

说下调试程序的个人经验。
解决棘手问题的方法没有固定套路，基本上是多管齐下，说不定最后会在哪条路上找到答案。认真思考使用方式有没有问题是一个途径；调试程序，从问题表现点（本例是段错误处）逐渐前推准确定位到问题产生点（错误使用处），也是一个可行途径。
楼主的问题根据目前的阐述，只有数据传输量很大的时候出错，且调试的时候难以重现。问题表现点在mb_size += i->size ();
我的建议是从这里开始向前跟，比如在前面加一个打印语句，后面加一个打印语句。如果前面的语句能打出来，然后是segmentation fault，后面的打印语句没有执行，可以肯定就是这个语句的问题。那么再用同样的方式，再用前面debug语句访问i的其他成员函数，打印i的值以及当前message有多大（如果只在大数据量时出问题这可能是关键临界值）等等。逐渐沿call stack向前推，最后定位到出问题的地方。这个地方可能在ace代码里更大的可能在楼主代码里。
这种方式应该难度不算太大，改一下ace源码make一下也就十几秒的事，加几句debug语句也不用改变程序执行逻辑。这是我个人在debuger失效时常用的调试方式，如果楼主实在novice做起来困难，当我没说过好了。
同建议楼主提供下更详细的使用信息，这样大家可以做白盒代码排查。