On Mon, Aug 11, 2008 at 7:58 PM, Pedro Gon?alves <pedro.pandre at gmail.com>wrote: > Hey Benny! > > I think I found the place where vptr seems to be getting corrupted! > > First of all, I have to say that I am saving the dialog(dlg in a singleton > class: SIPEngine::instance->dlg->remote.contact->uri) whose > remote.contact->uri's vptr value is invalid. > The dlg->remote.contact->uri gets updated from time to time so it's probably not a good idea to save the pointer there for a long time. > > Secondly, using Visual Studio I created a data breakpoint to check where > dlg->remote.contact->uri was being changed, and it showed me that it gains > invalid value in print_util.h's init_hdr. Here is the complete stack trace: The stack trace below just shows the standard initialization for Contact header, there's nothing wrong with that. > > > PCCommunicator.exe!init_hdr(void * hptr=0x0d8e9d88, pjsip_hdr_e > htype=PJSIP_H_CONTACT, void * vptr=0x0131825c) Line 129 C > PCCommunicator.exe!pjsip_contact_hdr_init(pj_pool_t * pool=0x0d8e8ff8, > void * mem=0x0d8e9d88) Line 1107 + 0x10 bytes C > PCCommunicator.exe!pjsip_contact_hdr_create(pj_pool_t * pool=0x0d8e8ff8) > Line 1116 + 0xd bytes C > PCCommunicator.exe!parse_hdr_contact(pjsip_parse_ctx * ctx=0x0dbbf20c) > Line 1712 + 0xc bytes C > PCCommunicator.exe!int_parse_msg(pjsip_parse_ctx * ctx=0x0dbbf20c, > pjsip_parser_err_report * err_list=0x0d8e9964) Line 963 + 0xc bytes C > PCCommunicator.exe!pjsip_parse_rdata(char * buf=0x0d8e90fc, unsigned int > size=0x00000400, pjsip_rx_data * rdata=0x0d8e905c) Line 758 + 0x12 bytes > C > PCCommunicator.exe!pjsip_tpmgr_receive_packet(pjsip_tpmgr * > mgr=0x0b50db68, pjsip_rx_data * rdata=0x0d8e905c) Line 1350 + 0x11 bytes > C > PCCommunicator.exe!udp_on_read_complete(pj_ioqueue_key_t * > key=0x0b50b78c, pj_ioqueue_op_key_t * op_key=0x0d8e9068, long > bytes_read=0x00000400) Line 165 + 0x16 bytes C > PCCommunicator.exe!ioqueue_dispatch_read_event(pj_ioqueue_t * > ioqueue=0x0b50b1d8, pj_ioqueue_key_t * h=0x0b50b78c) Line 550 + 0x16 bytes > C > PCCommunicator.exe!pj_ioqueue_poll(pj_ioqueue_t * ioqueue=0x0b50b1d8, > const pj_time_val * timeout=0x0dbbfcac) Line 763 + 0x17 bytes C > PCCommunicator.exe!pjsip_endpt_handle_events2(pjsip_endpoint * > endpt=0x0b8bd05c, const pj_time_val * max_timeout=0x0dbbfe7c, unsigned int * > p_count=0x00000000) Line 718 + 0x10 bytes C > PCCommunicator.exe!pjsip_endpt_handle_events(pjsip_endpoint * > endpt=0x0b8bd05c, const pj_time_val * max_timeout=0x0dbbfe7c) Line 745 + > 0xf bytes C > PCCommunicator.exe!EventHandler(void * __formal=0x00000000) Line 630 + > 0x16 bytes C++ > PCCommunicator.exe!thread_main(void * param=0x0b48df94) Line 413 + 0x11 > bytes C > > Thirdly, I can see that SIPEngine::instance->dlg->remote.contact->uri > points to 0x0d8e9d98. > In init_hdr, we have these lines: > hdr->name.ptr = pjsip_hdr_names[htype].name; > hdr->name.slen = pjsip_hdr_names[htype].name_len; > > I can see that pjsip_hdr_names[htype].name is "Contact" and, so > pjsip_hdr_names[htype].name_len is 7 (0x00000007) > Surprisingly or not, in init_hdr, &hdr->name.slen is precisely > *0x0d8e9d98*, so this is the instruction that "corrupts" > SIPEngine::instance->dlg->remote.contact->uri. > > That sounds bizarre. I don't know how that can happen, and I've spent the last couple of hours trying to figure out what could possibly cause that, and tried to force the condition, but I just can't reproduce it. > Tracing back the call to pjsip_contact_hdr_create, I can see that mem > points to 0x0d8e9d98 (SIPEngine::instance->dlg->remote.contact->uri's > location), which leads me to believe that there must be some kind of problem > with PJSIP's memory allocation system. > > Am I wrong? > Well can you prove that you're right? -benny > I attached the log, just in case it is needed. > > Cheers > Pedro Gon?alves > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080812/cbdf450c/attachment.html
