Benny Prijono wrote: > > On Tue, Aug 12, 2008 at 12:13 PM, Benny Prijono <bennylp at pjsip.org > <mailto:bennylp at pjsip.org>> wrote: > > On Mon, Aug 11, 2008 at 7:58 PM, Pedro Gon?alves > <pedro.pandre at gmail.com <mailto: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. > > > > Actually the stack trace is wrong. The dlg->remote.contact->uri is > never initialized like the stack trace shows, since it should have > come from pjsip_contact_hdr_clone() instead. So you're watching the > wrong variable. > > -benny Sorry, maybe I didn't make myself clear. I'm not saying that dlg->remote.contact->uri is initialized this way. I am saying that dlg->remote.contact->uri gets corrupted by the mentioned stack trace. I can reproduce this behaviour all the time. It seems to me that the problem starts in pjsip_contact_hdr_create(), where a pj_pool_alloc() is made. I set a breakpoint there, and I can see that this instruction: void *mem = pj_pool_alloc(pool, sizeof(pjsip_contact_hdr)); makes mem point to 0x0d9a9d88. The problem is that SIPEngine::instance->dlg->remote.contact->uri points to 0x0d9a9d98. This way, mem will be overlapped with SIPEngine::instance->dlg->remote.contact->uri, thus corrupting it when writing to its location (which happens in init_hdr). Any idea why this happens? Why does pj_pool_alloc return a pointer to an occupied zone? Do you think that for some reason the pool where SIPEngine::instance->dlg->remote.contact->uri is (is it SIPEngine::instance->dlg->pool?) was released?! Thanks for your precious help Pedro Gon?alves