Re: [Ekiga-devel-list] Real Issue is Opal::Call virtual table missing



Hi Julien
http://www.filebin.ca/TB8qsM5SLRW/gdb-ekiga.txt.gz
I run with new patch.
here new result.  The object call still is lost.
Not success but I still want to thank you for everything you done.
Best Regards,
Lorin

My observation note:
I suspect the object call between Opal and Ekiga is not working
together properly.
For example Opal destroy the call after first success incoming call
and hungup ( by either side). The Ekiga protocol is suppose to follow
the new created call by the Opal for next incoming call.
Even though the Opal created a new call object in second incoming
call, Ekiga protocol does not aware of new call object.

Ekiga still has problem keeping up successive incoming calls:
New create call in first incoming
Eikga::Call constructor called!!
OPAL::Call constructor called !!
Opal::CallManager::CreateCall Create call!! uri: 2013/01/11
11:41:19.446          0:23.716       Opal Answer:0xa53cdb40 OpalCon
Created connection
Call[Cb394179b1]-EP<h323>[tcp$65.130.133.228:52006/17023]

Opal already destoyed Call
2013/01/11 11:41:39.159   0:43.430      Opal Garbage:0xad62eb40
OpalMan Trying call ::CallDict::DeleteObject manager.DestroyCall!
2013/01/11 11:41:39.206   0:43.476                              Call
 Destroyed Call[Cb394179b1]
Ekiga does not track the Call!

Watch for next incoming call
2013/01/11 11:41:44.847   0:49.117       Opal Answer:0xa53cdb40 H225
 Incoming call, first PDU: callReference=17024
2013/01/11 11:41:44.847   0:49.117       Opal Answer:0xa53cdb40 Call
 Created Call[C401ef3e23]
2013/01/11 11:41:44.847   0:49.117       Opal Answer:0xa53cdb40
OpalCon Created connection
Call[C401ef3e23]-EP<h323>[tcp$65.130.133.228:52008/17024]
Ekiga does not know the new call has been recreated by the Opal

Then libnofity call->answer was based on the old call which has been
destroyed already. Here is crash of pure virtual method.

My concerns are the Ekiga is not able to keep up Opal's Call
"destroyed and created incoming call" cycle.  Once in while I observed
the Ekiga follow destroyed call. This event is rare !
see example of destroying call:

OpalCall *CallManager Destroy call!!
OPAL::Call is destroyed !!
Eikga::Call destroyed!!
2013/01/07 21:55:32.064   1:25.166                              Call
 Destroyed Call[Cd1ef5ab91]


On Fri, Jan 11, 2013 at 10:26 AM, Julien Puydt <jpuydt free fr> wrote:
> Le 09/01/2013 08:37, Julien Puydt a écrit :
>>
>> Le 09/01/2013 00:16, Lorin Melander a écrit :
>>>
>>> Ekiga::Call *call = (Ekiga::Call *) data;<---- is this you want to know ?
>
>
>> YES! That is what I wanted to know! It's a bare pointer! Nothing smart
>> in it! No wonder the object gets destroyed in our back: we don't hold
>> any reference to it officially!
>
>
> Here is a patch -- can you confirm it fixes the issue?
>
> Snark
>
> _______________________________________________
> ekiga-devel-list mailing list
> ekiga-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/ekiga-devel-list



-- 
-lorin


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