Hi there, we've been observing recurring crashes in one of our clients' applications and all the information we could gather pointed to Sofia's address space, but we couldn't pinpoint exactly where. Yesterday, after a bit of digging around and successfully setting up the client's environment to run valgrind, we were able to obtain the following backtrace for the problem:
==2608== ==2608== Thread 11: ==2608== Invalid read of size 4 ==2608== at 0x40BEE93: nua_prack_server_report (nua_session.c:2893) ==2608== by 0x40A74CE: nua_server_report (nua_stack.c:1827) ==2608== by 0x40A6AC3: nua_stack_respond (nua_stack.c:1633) ==2608== by 0x40A45BF: nua_stack_signal (nua_stack.c:650) ==2608== by 0x40FF0B3: su_base_port_execute_msgs (su_base_port.c:276) ==2608== by 0x40FEE1F: su_base_port_getmsgs (su_base_port.c:198) ==2608== by 0x40FF175: su_base_port_run (su_base_port.c:331) ==2608== by 0x40FCFCA: su_port_run (su_port.h:310) ==2608== by 0x40FC2BF: su_root_run (su_root.c:689) ==2608== by 0x40FFCF7: su_pthread_port_clone_main (su_pthread_port.c:321) ==2608== by 0x41B30CD: pthread_start_thread (manager.c:291) ==2608== by 0x4321739: clone (in /lib/libc-2.2.4.so) ==2608== Address 0x4c3d67c is 68 bytes inside a block of size 72 free'd ==2608== at 0x401A61F: free (m_replacemalloc/vg_replace_malloc.c:323) ==2608== by 0x40F7464: su_free (su_alloc.c:838) ==2608== by 0x40A688F: nua_server_request_destroy (nua_stack.c:1504) ==2608== by 0x40BE3AE: process_ack (nua_session.c:2573) ==2608== by 0x40BDCBB: process_ack_or_cancel (nua_session.c:2477) ==2608== by 0x408CE3C: incoming_call_callback (nta.c:6117) ==2608== by 0x408CAD3: incoming_ack (nta.c:6009) ==2608== by 0x40852BD: agent_recv_request (nta.c:2891) ==2608== by 0x4084478: agent_recv_message (nta.c:2722) ==2608== by 0x4111903: tport_base_deliver (tport.c:3013) ==2608== by 0x4111896: tport_deliver (tport.c:3002) ==2608== by 0x4111456: tport_parse (tport.c:2919) If I'm reading this correctly, it seems the application is trying to do something strange (send a PRACK after receiving and ACK, is that what it is?). Nevertheless, I believe the stack should detect this situation and be protected from the crash. Could anybody please help me figure out how to correct this? Is this by any chance already caught and corrected in the latest darcs? Thanks in advance. Fabio ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
