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

[Lorin Melander <lwmelander gmail com>]

Snark,
In other word the redial is not reliable.  I observed the libnotify
tries to access the Opal::Call at second answer then pure virtual
method crash.

I notice call->hungup and call->answer both have same problem.
The boost library should have help the libnotify to follow the Opal::Call.

I do not know why the libnotify to reach Ekiga::Call which is pure
virtual class.

-Lorin

On Mon, Jan 7, 2013 at 9:12 AM, Julien Puydt <jpuydt free fr> wrote:
> Le 07/01/2013 16:22, Lorin Melander a écrit :
>
>> I observed the Virtual Table of Opal::Call is missing at second answer
>> or hungup.
>> First answer
>> (gdb) print *call
>> $1 = {_vptr.Call = 0xb7e7d660<vtable for Opal::Call+256>
>> Ekiga answers successfully.
>>
>> 2nd answer
>> (gdb) print *call
>> $1 = {_vptr.Call = 0x33352020,
>> Ekiga crashs with pure virtual method.
>>
>> The second answer or hungup will have pure virtual method crash since
>> the *call could not find Opal::Call.
>
>
> Doesn't that mean that the *call object is partially destructed already?
>
>
>> I notice that the boost::bind or boost::signal is not really reliable
>> following the Opal::Call object.
>
>
> Could you explain what that sentence means?
>
> Snark
>
> _______________________________________________
> ekiga-devel-list mailing list
> ekiga-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/ekiga-devel-list



-- 
-lorin