Le 16/09/12 22:54, Julien Puydt a écrit :
Le 16/09/2012 22:19, Julien Puydt a écrit :
I don't think it explains any crash or freeze, but it will at least
avoid a discrepancy between the internal state of the account and what
the user interface displays about it.
Sigh ; here is what the crash I see looks like :
(gdb) bt
#0 0x00007ffff3d2f957 in PWaitAndSignal::PWaitAndSignal(PSync const&,
bool) () from /usr/lib/libopal.so.3.10-beta8
#1 0x00007ffff414d961 in SIPHandlersList::FindBy(std::map<PString,
PSafePtr<SIPHandler, PSafePtrBase>, std::less<PString>,
std::allocator<std::pair<PString const, PSafePtr<SIPHandler,
PSafePtrBase> > > >&, PString const&, PSafetyMode) () from
/usr/lib/libopal.so.3.10-beta8
#2 0x00007ffff414dc08 in
SIPHandlersList::FindSIPHandlerByCallID(PString const&, PSafetyMode)
() from /usr/lib/libopal.so.3.10-beta8
#3 0x00007ffff40f874a in SIPEndPoint::Unsubscribe(PString const&,
PString const&, bool) () from /usr/lib/libopal.so.3.10-beta8
#4 0x00007ffff40f86de in
SIPEndPoint::Unsubscribe(SIPSubscribe::PredefinedPackages, PString
const&, bool) () from /usr/lib/libopal.so.3.10-beta8
#5 0x00007ffff4158c0a in SIP_Presentity::Close() () from
/usr/lib/libopal.so.3.10-beta8
#6 0x00007ffff77bc5aa in Main (this=0xeb7940) at
../../ekiga.git/lib/engine/components/opal/sip-endpoint.cpp:104
#7 Opal::Sip::subscriber::Main (this=0xeb7940) at
../../ekiga.git/lib/engine/components/opal/sip-endpoint.cpp:92
#8 0x00007ffff32d2675 in PThread::PX_ThreadStart(void*) () from
/usr/lib/libpt.so.2.10-beta8
#9 0x00007ffff1eceb50 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#10 0x00007ffff1c1970d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#11 0x0000000000000000 in ?? ()
It's a freeze (deadlock), right ?
It happens when I play in the account edition window, and is generally
triggered by doing the following :
- activate the account so it tries to do something ;
- modify the account (let it active in the edit account window) ;
- disactivate the account from the button in the accounts window.
I don't experience this...
Here is part of the code of Opal::Account::disable, which is probably
the culprit since it's clicking on the disabling which triggers the
segfault :
endpoint->unsubscribe (*this, presentity);
if (presentity) {
// FIXME : the following actions should probably be done by opal
itself,
// remembering what ekiga asked...
for (std::set<std::string>::iterator iter = watched_uris.begin ();
iter != watched_uris.end (); ++iter) {
presentity->UnsubscribeFromPresence (PString (*iter));
Now that raises a few questions:
(1) I see a SIP_Presentity::Close in the backtrace, which is probably
triggered by the call to endpoint->unsubscribe()... which as far as I
understand, runs in parallel with the later code where we do
presentity->UnsubscribeFromPresence... so if the presentity object has
thread-safety issues, perhaps that explains the crash?
Most probably !
(2) what was this loop on watched_uris about anyway? [I don't
remember...]
It looks like if we unregister the account, we also trigger presence
unsubscription for all uris we are subscribed to.
This could/should be done by OPAL itself.
Damien
_______________________________________________
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/ekiga-devel-list