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
|
