18 个解决方案
#1
代码呢
#2
这基本不可能吧
#3
does ur source code involve multithreading or multiprocessing?
debugging will break the scheduling for execution that could otherwise introduce bugs on their normal schedule...
debugging will break the scheduling for execution that could otherwise introduce bugs on their normal schedule...
#4
core dump 一下
#5
代码有很多，贴上了很不方便。我程序处理里面加了多线程
#6
很有可能，现在段错误解决了。我的代码主要是用sip协议来写message，invite的， 我把测试函数直接放在单线程环境里面运行，结果没有问题，但是把函数作为线程函数的时候结果出现超时，但是我用抓包软件去过滤报文的时候发现其实message和invite都已经成功发送，而且以后response，但是加在函数体里面的调试显示打印出来的是超时？
#7
yes, there is multithreading in my code. Now the problem is that when i execute the program as a single thread, the result is what i want, but when i deal with the function as a thread function, the outcome is timeout in the debug information(which i use "printf" to print).
#8
well, you might need some synchronization in multithreading environment. Without seeing ur code, no one can help.
you could try the debug tools, such as valgrind, but you got know what you are doing...
#9
eXosip_message_send_request success!
at 1.
No response or the time is over (in sip_invite)!
at 2.
No response or the time is over(in sip_get_list)!
==2213==
==2213== HEAP SUMMARY:
==2213== in use at exit: 28,204 bytes in 1,643 blocks
==2213== total heap usage: 2,479 allocs, 836 frees, 100,172 bytes allocated
==2213==
==2213== 30 bytes in 1 blocks are definitely lost in loss record 855 of 1,024
==2213== at 0x40299D8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2213== by 0x4085BF9: osip_uri_to_str (osip_uri.c:558)
==2213== by 0x80496C7: create_uri (l_osip.c:24)
==2213== by 0x8049E83: sip_register (ua.c:102)
==2213== by 0x8049795: main (main.c:50)
==2213==
==2213== 38 bytes in 1 blocks are definitely lost in loss record 937 of 1,024
==2213== at 0x40299D8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2213== by 0x4085BF9: osip_uri_to_str (osip_uri.c:558)
==2213== by 0x80496C7: create_uri (l_osip.c:24)
==2213== by 0x8049E54: sip_register (ua.c:101)
==2213== by 0x8049795: main (main.c:50)
==2213==
==2213== 136 bytes in 1 blocks are possibly lost in loss record 1,003 of 1,024
==2213== at 0x402B965: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2213== by 0x4011627: allocate_dtv (dl-tls.c:296)
==2213== by 0x4011DBB: _dl_allocate_tls (dl-tls.c:460)
==2213== by 0x40B04BE: pthread_create@@GLIBC_2.1 (allocatestack.c:579)
==2213== by 0x40B0AF0: pthread_create@GLIBC_2.0 (pthread_create.c:623)
==2213== by 0x4049D46: eXosip_listen_addr (eXconf.c:560)
==2213== by 0x8049E18: sip_register (ua.c:94)
==2213== by 0x8049795: main (main.c:50)
==2213==
==2213== 136 bytes in 1 blocks are possibly lost in loss record 1,004 of 1,024
==2213== at 0x402B965: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2213== by 0x4011627: allocate_dtv (dl-tls.c:296)
==2213== by 0x4011DBB: _dl_allocate_tls (dl-tls.c:460)
==2213== by 0x40B04BE: pthread_create@@GLIBC_2.1 (allocatestack.c:579)
==2213== by 0x80497B9: main (main.c:51)
==2213==
==2213== 136 bytes in 1 blocks are possibly lost in loss record 1,005 of 1,024
==2213== at 0x402B965: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2213== by 0x4011627: allocate_dtv (dl-tls.c:296)
==2213== by 0x4011DBB: _dl_allocate_tls (dl-tls.c:460)
==2213== by 0x40B04BE: pthread_create@@GLIBC_2.1 (allocatestack.c:579)
==2213== by 0x8049800: main (main.c:59)
==2213==
==2213== 5,674 (616 direct, 5,058 indirect) bytes in 2 blocks are definitely lost in loss record 1,024 of 1,024
==2213== at 0x40299D8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2213== by 0x4063E9E: eXosip_event_init (jevents.c:185)
==2213== by 0x4063DBB: eXosip_event_init_for_reg (jevents.c:154)
==2213== by 0x4059664: rcvregister_failure (jcallback.c:1370)
==2213== by 0x4059AEF: cb_rcv4xx (jcallback.c:1488)
==2213== by 0x4285213: __osip_message_callback (osip.c:2034)
==2213== by 0x42801B6: nict_rcv_23456xx (nict_fsm.c:288)
==2213== by 0x4282725: fsm_callmethod (fsm_misc.c:66)
==2213== by 0x4285F9A: osip_transaction_execute (osip_transaction.c:377)
==2213== by 0x42844D6: osip_nict_execute (osip.c:1595)
==2213== by 0x404A148: _eXosip_execute (eXconf.c:684)
==2213== by 0x404A585: _eXosip_thread (eXconf.c:807)
==2213==
==2213== LEAK SUMMARY:
==2213== definitely lost: 684 bytes in 4 blocks
==2213== indirectly lost: 5,058 bytes in 354 blocks
==2213== possibly lost: 408 bytes in 3 blocks
==2213== still reachable: 22,054 bytes in 1,282 blocks
==2213== suppressed: 0 bytes in 0 blocks
==2213== Reachable blocks (those to which a pointer was found) are not shown.
==2213== To see them, rerun with: --leak-check=full --show-reachable=yes
==2213==
==2213== For counts of detected and suppressed errors, rerun with: -v
==2213== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 0 from 0)
#10
these "leaks" may or may not be the real memory leaks. Valgrind just told you that u forgot to free them. It is usually fine if the program is not run as a daemon.
but you could use this report as your check list to discover potential memory related bug.
If nothing is wrong, you could try Helgrind and which are tools under valgrind tool suite for detecting bugs in multithreading environment...
#11
I meant to say you could try "Helgrind and DRD"
#12
get it, i try it. do you have some relevant materials about the tool, i think it is a powerful tool. i prefer to learn it deeply.
#13
the best place for learning valgrind is its website: http://valgrind.org/
#14
你把SIP库的debug模式都开了，有助于你调试
#15
恩恩，谢谢提醒
#16
应该是时序的问题
#17
嗯，时序问题要从哪里下手啊，我是小白一只
#18
多线程，socket编程，gdb下可能会发生超时丢包的现象，这样程序的运行逻辑跟正常运行时就不一样了；
另外，gdb时虽然程序是中断了，但系统还在运行，包括系统时间，资源占用等都在改变，这也可能导致跟正常运行时逻辑不一样；
当然还有别的情况。
#1
代码呢
#2
这基本不可能吧
#3
does ur source code involve multithreading or multiprocessing?
debugging will break the scheduling for execution that could otherwise introduce bugs on their normal schedule...
debugging will break the scheduling for execution that could otherwise introduce bugs on their normal schedule...
#4
core dump 一下
#5
代码有很多，贴上了很不方便。我程序处理里面加了多线程
#6
很有可能，现在段错误解决了。我的代码主要是用sip协议来写message，invite的， 我把测试函数直接放在单线程环境里面运行，结果没有问题，但是把函数作为线程函数的时候结果出现超时，但是我用抓包软件去过滤报文的时候发现其实message和invite都已经成功发送，而且以后response，但是加在函数体里面的调试显示打印出来的是超时？
#7
yes, there is multithreading in my code. Now the problem is that when i execute the program as a single thread, the result is what i want, but when i deal with the function as a thread function, the outcome is timeout in the debug information(which i use "printf" to print).
#8
well, you might need some synchronization in multithreading environment. Without seeing ur code, no one can help.
you could try the debug tools, such as valgrind, but you got know what you are doing...
#9
eXosip_message_send_request success!
at 1.
No response or the time is over (in sip_invite)!
at 2.
No response or the time is over(in sip_get_list)!
==2213==
==2213== HEAP SUMMARY:
==2213== in use at exit: 28,204 bytes in 1,643 blocks
==2213== total heap usage: 2,479 allocs, 836 frees, 100,172 bytes allocated
==2213==
==2213== 30 bytes in 1 blocks are definitely lost in loss record 855 of 1,024
==2213== at 0x40299D8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2213== by 0x4085BF9: osip_uri_to_str (osip_uri.c:558)
==2213== by 0x80496C7: create_uri (l_osip.c:24)
==2213== by 0x8049E83: sip_register (ua.c:102)
==2213== by 0x8049795: main (main.c:50)
==2213==
==2213== 38 bytes in 1 blocks are definitely lost in loss record 937 of 1,024
==2213== at 0x40299D8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2213== by 0x4085BF9: osip_uri_to_str (osip_uri.c:558)
==2213== by 0x80496C7: create_uri (l_osip.c:24)
==2213== by 0x8049E54: sip_register (ua.c:101)
==2213== by 0x8049795: main (main.c:50)
==2213==
==2213== 136 bytes in 1 blocks are possibly lost in loss record 1,003 of 1,024
==2213== at 0x402B965: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2213== by 0x4011627: allocate_dtv (dl-tls.c:296)
==2213== by 0x4011DBB: _dl_allocate_tls (dl-tls.c:460)
==2213== by 0x40B04BE: pthread_create@@GLIBC_2.1 (allocatestack.c:579)
==2213== by 0x40B0AF0: pthread_create@GLIBC_2.0 (pthread_create.c:623)
==2213== by 0x4049D46: eXosip_listen_addr (eXconf.c:560)
==2213== by 0x8049E18: sip_register (ua.c:94)
==2213== by 0x8049795: main (main.c:50)
==2213==
==2213== 136 bytes in 1 blocks are possibly lost in loss record 1,004 of 1,024
==2213== at 0x402B965: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2213== by 0x4011627: allocate_dtv (dl-tls.c:296)
==2213== by 0x4011DBB: _dl_allocate_tls (dl-tls.c:460)
==2213== by 0x40B04BE: pthread_create@@GLIBC_2.1 (allocatestack.c:579)
==2213== by 0x80497B9: main (main.c:51)
==2213==
==2213== 136 bytes in 1 blocks are possibly lost in loss record 1,005 of 1,024
==2213== at 0x402B965: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2213== by 0x4011627: allocate_dtv (dl-tls.c:296)
==2213== by 0x4011DBB: _dl_allocate_tls (dl-tls.c:460)
==2213== by 0x40B04BE: pthread_create@@GLIBC_2.1 (allocatestack.c:579)
==2213== by 0x8049800: main (main.c:59)
==2213==
==2213== 5,674 (616 direct, 5,058 indirect) bytes in 2 blocks are definitely lost in loss record 1,024 of 1,024
==2213== at 0x40299D8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2213== by 0x4063E9E: eXosip_event_init (jevents.c:185)
==2213== by 0x4063DBB: eXosip_event_init_for_reg (jevents.c:154)
==2213== by 0x4059664: rcvregister_failure (jcallback.c:1370)
==2213== by 0x4059AEF: cb_rcv4xx (jcallback.c:1488)
==2213== by 0x4285213: __osip_message_callback (osip.c:2034)
==2213== by 0x42801B6: nict_rcv_23456xx (nict_fsm.c:288)
==2213== by 0x4282725: fsm_callmethod (fsm_misc.c:66)
==2213== by 0x4285F9A: osip_transaction_execute (osip_transaction.c:377)
==2213== by 0x42844D6: osip_nict_execute (osip.c:1595)
==2213== by 0x404A148: _eXosip_execute (eXconf.c:684)
==2213== by 0x404A585: _eXosip_thread (eXconf.c:807)
==2213==
==2213== LEAK SUMMARY:
==2213== definitely lost: 684 bytes in 4 blocks
==2213== indirectly lost: 5,058 bytes in 354 blocks
==2213== possibly lost: 408 bytes in 3 blocks
==2213== still reachable: 22,054 bytes in 1,282 blocks
==2213== suppressed: 0 bytes in 0 blocks
==2213== Reachable blocks (those to which a pointer was found) are not shown.
==2213== To see them, rerun with: --leak-check=full --show-reachable=yes
==2213==
==2213== For counts of detected and suppressed errors, rerun with: -v
==2213== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 0 from 0)
#10
these "leaks" may or may not be the real memory leaks. Valgrind just told you that u forgot to free them. It is usually fine if the program is not run as a daemon.
but you could use this report as your check list to discover potential memory related bug.
If nothing is wrong, you could try Helgrind and which are tools under valgrind tool suite for detecting bugs in multithreading environment...
#11
I meant to say you could try "Helgrind and DRD"
#12
get it, i try it. do you have some relevant materials about the tool, i think it is a powerful tool. i prefer to learn it deeply.
#13
the best place for learning valgrind is its website: http://valgrind.org/
#14
你把SIP库的debug模式都开了，有助于你调试
#15
恩恩，谢谢提醒
#16
应该是时序的问题
#17
嗯，时序问题要从哪里下手啊，我是小白一只
#18
多线程，socket编程，gdb下可能会发生超时丢包的现象，这样程序的运行逻辑跟正常运行时就不一样了；
另外，gdb时虽然程序是中断了，但系统还在运行，包括系统时间，资源占用等都在改变，这也可能导致跟正常运行时逻辑不一样；
当然还有别的情况。