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

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.


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


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