pjsip_uri_cmp: uri1's vptr has invalid value exception

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux