Crash on... startup!

[Julien PUYDT]

Hi,

I had a nice surprise this morning, trying to launch ekiga :

#0  0xb661a9bb in
std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*,
std::_Rb_tree_node_base&) () from /usr/lib/libstdc++.so.6
#1  0xb7c4b7fd in std::map<PString, PSafePtr<SIPHandler, PSafePtrBase>,
std::less<PString>, std::allocator<std::pair<PString const,
PSafePtr<SIPHandler, PSafePtrBase> > >
 >::erase(std::_Rb_tree_iterator<std::pair<PString const,
PSafePtr<SIPHandler, PSafePtrBase> > >) () from
/usr/lib/libopal.so.3.7-beta1
#2  0xb7c436a9 in SIPHandlersList::Remove(SIPHandler*) ()
    from /usr/lib/libopal.so.3.7-beta1
#3  0xb7c17759 in SIPEndPoint::GarbageCollection() ()
    from /usr/lib/libopal.so.3.7-beta1
#4  0xb792f594 in OpalManager::GarbageCollection() ()
    from /usr/lib/libopal.so.3.7-beta1
#5  0xb792f622 in OpalManager::GarbageMain(PThread&, int) ()
    from /usr/lib/libopal.so.3.7-beta1
#6  0xb793526b in OpalManager::GarbageMain_PNotifier::Call(PObject&,
int) const
     () from /usr/lib/libopal.so.3.7-beta1
#7  0xb7f170b7 in PNotifierTemplate<int>::operator() (this=0x821e4e0,
     notifier=..., extra=0) at /usr/include/ptlib/notifier.h:129
#8  0xb755b3de in PSimpleThread::Main() () from /usr/lib/libpt.so.2.7-beta1
#9  0xb7535f8f in PThread::PX_ThreadStart(void*) ()
    from /usr/lib/libpt.so.2.7-beta1
#10 0xb67c64b5 in start_thread () from /lib/i686/cmov/libpthread.so.0
#11 0xb64f8a5e in clone () from /lib/i686/cmov/libc.so.6


It looks like a bug we had in ekiga recently : a loop in which we remove
something... which invalidates the iterator!

I'll try to update my ptlib&opal to see if I have just been unlucky.

Snark
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Julien PUYDT]

Julien Puydt a écrit :
> I'll try to update my ptlib&opal to see if I have just been unlucky.

No love : still crashing.

Snark
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Michael Rickmann]

I have it with Win32 Ekiga master too:
http://mail.gnome.org/archives/ekiga-devel-list/2009-October/msg00000.html
I switched back to Opal 2345 and Ptlib 23543. If your crash disappears
without apparent reason try to remember what you did. Damien said he
does not have it.
Michael

Julien Puydt schrieb:

> Julien Puydt a écrit :
>> I'll try to update my ptlib&opal to see if I have just been unlucky.
>
> No love : still crashing.
>
> Snark
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-list@...
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Julien PUYDT]

Julien Puydt a écrit :
> I had a nice surprise this morning, trying to launch ekiga :

Eh, funny piece of information : when I'm off-network, then ekiga runs
correctly.

Since a few weeks, I haven't had time to use or hack on ekiga at home
(ie: online), only during spare time at work (that's few... and offline)
-- so perhaps that problem is several weeks old and I couldn't notice :-(

Snark

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Michael Rickmann]

I think I know what is happening Opal tries to insert entries with
duplicate keys into a map. Look at attached log. I had inserted an extra
cerr line into opal/src/sip/handlers.cxx:1633.
  handler->m_byAOR =
m_byAOR.insert(IndexMap::value_type(MakeUrlKey(handler->GetAddressOfRecord(), handler->GetMethod()), handler)).first;
cerr << "******** m_byAOR.insert: " <<
MakeUrlKey(handler->GetAddressOfRecord(), handler->GetMethod()) << endl;

This was from a computer with two interfaces a public one 134.76.145.30%
eth0 and a private one 192.168.21.30%eth1. E.g. for 500@... Ekiga
starts a subscriber for each of the interfaces, but opal constructs the
same key for the map, the second one will presumably not be inserted but
is falsely deleted when the subscriber finishes.
Michael

Am Donnerstag, den 08.10.2009, 06:52 +0200 schrieb Julien Puydt:

> Julien Puydt a écrit :
> > I'll try to update my ptlib&opal to see if I have just been unlucky.
>
> No love : still crashing.
>
> Snark
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-list@...
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Julien PUYDT]

Julien Puydt a écrit :
> I had a nice surprise this morning, trying to launch ekiga :
> I'll try to update my ptlib&opal to see if I have just been unlucky.

I retried this evening : still crashing :-(

Snark
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Michael Rickmann]

Julien Puydt schrieb:
> Julien Puydt a écrit :
>> I had a nice surprise this morning, trying to launch ekiga :
>> I'll try to update my ptlib&opal to see if I have just been unlucky.
>
> I retried this evening : still crashing :-(
>
> Snark
> _______________________________________________

I tried this evening on WIN32 : still crashing.
I guess we will have to exercise patience.
I made shure that the reason for the crash is mainly in Opal's
handlers.cxx index maps and not in Ekiga's heap. With attached patch
Ekiga works.
Michael

diff -ur src/opal/include/sip/handlers.h opal/include/sip/handlers.h
--- src/opal/include/sip/handlers.h 2009-10-09 14:40:45.000000000 +0200
+++ opal/include/sip/handlers.h 2009-10-13 18:00:33.000000000 +0200
@@ -166,8 +166,9 @@
   OpalProductInfo             m_productInfo;
 
   // Keep a copy of the keys used for easy removal on destruction
-  typedef std::map<PString, PSafePtr<SIPHandler> > IndexMap;
+  typedef std::multimap<PString, PSafePtr<SIPHandler> > IndexMap;
   IndexMap::iterator m_byCallID;
+  IndexMap::iterator m_byAOR;
   IndexMap::iterator m_byAorAndPackage;
   IndexMap::iterator m_byAuthIdAndRealm;
   IndexMap::iterator m_byAorUserAndRealm;
@@ -417,6 +418,7 @@
     PSafePtr<SIPHandler> FindBy(IndexMap & by, const PString & key, PSafetyMode m);
 
     IndexMap m_byCallID;
+    IndexMap m_byAOR;
     IndexMap m_byAorAndPackage;
     IndexMap m_byAuthIdAndRealm;
     IndexMap m_byAorUserAndRealm;
diff -ur src/opal/src/sip/handlers.cxx opal/src/sip/handlers.cxx
--- src/opal/src/sip/handlers.cxx 2009-10-09 14:40:46.000000000 +0200
+++ opal/src/sip/handlers.cxx 2009-10-13 18:01:48.000000000 +0200
@@ -89,7 +89,7 @@
   transactions.DisallowDeleteObjects();
   expireTimer.SetNotifier(PCREATE_NOTIFIER(OnExpireTimeout));
 
-  PTRACE(4, "SIP\tConstructed handler for " << params.m_addressOfRecord);
+  PTRACE(4, "SIP\tConstructed handler\n" << params);
 }
 
 
@@ -1621,16 +1621,19 @@
   PSafePtr<SIPHandler> handler = m_handlersList.Append(obj, PSafeReference);
 
   // add entry to call to handler map
-  handler->m_byCallID = m_byCallID.insert(IndexMap::value_type(handler->GetCallID(), handler)).first;
+  handler->m_byCallID = m_byCallID.insert(IndexMap::value_type(handler->GetCallID(), handler));
+
+  // add entry to url map
+  handler->m_byAOR = m_byAOR.insert(IndexMap::value_type(MakeUrlKey(handler->GetAddressOfRecord(), handler->GetMethod()), handler));
 
   // add entry to url and package map
-  handler->m_byAorAndPackage = m_byAorAndPackage.insert(IndexMap::value_type(MakeUrlKey(handler->GetAddressOfRecord(), handler->GetMethod(), handler->GetEventPackage()), handler)).first;
+  handler->m_byAorAndPackage = m_byAorAndPackage.insert(IndexMap::value_type(MakeUrlKey(handler->GetAddressOfRecord(), handler->GetMethod(), handler->GetEventPackage()), handler));
 
   // add entry to username/realm map
   if (!handler->GetUsername().IsEmpty())
-    handler->m_byAuthIdAndRealm = m_byAuthIdAndRealm.insert(IndexMap::value_type(handler->GetUsername() + '\n' + handler->GetRealm(), handler)).first;
+    handler->m_byAuthIdAndRealm = m_byAuthIdAndRealm.insert(IndexMap::value_type(handler->GetUsername() + '\n' + handler->GetRealm(), handler));
 
-  handler->m_byAorUserAndRealm = m_byAorUserAndRealm.insert(IndexMap::value_type(handler->GetAddressOfRecord().GetUserName() + '\n' + handler->GetRealm(), handler)).first;
+  handler->m_byAorUserAndRealm = m_byAorUserAndRealm.insert(IndexMap::value_type(handler->GetAddressOfRecord().GetUserName() + '\n' + handler->GetRealm(), handler));
 }
 
 
@@ -1646,6 +1649,7 @@
 
   if (m_handlersList.Remove(handler)) {
     m_byCallID.erase(handler->m_byCallID);
+    m_byAOR.erase(handler->m_byAOR);
     m_byAorAndPackage.erase(handler->m_byAorAndPackage);
     m_byAuthIdAndRealm.erase(handler->m_byAuthIdAndRealm);
     m_byAorUserAndRealm.erase(handler->m_byAorUserAndRealm);
@@ -1686,7 +1690,7 @@
 
 PSafePtr<SIPHandler> SIPHandlersList::FindSIPHandlerByUrl(const PURL & aor, SIP_PDU::Methods method, PSafetyMode mode)
 {
-  return FindBy(m_byAorAndPackage, MakeUrlKey(aor, method), mode);
+  return FindBy(m_byAOR, MakeUrlKey(aor, method), mode);
 }
 
 

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le mardi 13 octobre 2009 à 19:26 +0200, Michael Rickmann a écrit :

> Julien Puydt schrieb:
> > Julien Puydt a écrit :
> >> I had a nice surprise this morning, trying to launch ekiga :
> >> I'll try to update my ptlib&opal to see if I have just been unlucky.
> >
> > I retried this evening : still crashing :-(
> >
> > Snark
> > _______________________________________________
>
> I tried this evening on WIN32 : still crashing.
> I guess we will have to exercise patience.
> I made shure that the reason for the crash is mainly in Opal's
> handlers.cxx index maps and not in Ekiga's heap. With attached patch
> Ekiga works.

I'll insist with Robert, but currently he does not answer me anymore.

--
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras@...
                       

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le mardi 13 octobre 2009 à 20:19 +0200, Damien Sandras a écrit :

> Le mardi 13 octobre 2009 à 19:26 +0200, Michael Rickmann a écrit :
> > Julien Puydt schrieb:
> > > Julien Puydt a écrit :
> > >> I had a nice surprise this morning, trying to launch ekiga :
> > >> I'll try to update my ptlib&opal to see if I have just been unlucky.
> > >
> > > I retried this evening : still crashing :-(
> > >
> > > Snark
> > > _______________________________________________
> >
> > I tried this evening on WIN32 : still crashing.
> > I guess we will have to exercise patience.
> > I made shure that the reason for the crash is mainly in Opal's
> > handlers.cxx index maps and not in Ekiga's heap. With attached patch
> > Ekiga works.
>
> I'll insist with Robert, but currently he does not answer me anymore.
>

Is this your crash :
(gdb) bt
#0  0xb6f7d44f in __exchange_and_add (__mem=0xb521ab02, __val=-1)
at /usr/include/c++/4.3/ext/atomicity.h:51
#1  0xb6f8cc3b in PAtomicInteger::operator-- (this=0xb521ab02)
at /usr/include/ptlib/critsec.h:248
#2  0xb6ac0dfb in PContainer::Destruct (this=0xb541bb18) at
ptlib/common/contain.cxx:123
#3  0xb7f19e8d in ~PAbstractArray (this=0xb541bb18, __in_chrg=<value
optimized out>) at /usr/include/ptlib/array.h:69
#4  ~PBaseArray (this=0xb541bb18, __in_chrg=<value optimized out>)
at /usr/include/ptlib/array.h:271
#5  ~PCharArray (this=0xb541bb18, __in_chrg=<value optimized out>)
at /usr/include/ptlib/array.h:564
#6  ~PString (this=0xb541bb18, __in_chrg=<value optimized out>)
at /usr/include/ptlib/pstring.h:102
#7  0xb73cf93d in ~pair (this=0xb541bb18, __in_chrg=<value optimized
out>) at /usr/include/c++/4.3/bits/stl_pair.h:73
#8  0xb73cf961 in __gnu_cxx::new_allocator<std::pair<PString const,
PSafePtr<SIPHandler, PSafePtrBase> > >::destroy (this=0xb555013f,
__p=0xb541bb18)
    at /usr/include/c++/4.3/ext/new_allocator.h:118
#9  0xb73cf9a5 in std::_Rb_tree<PString, std::pair<PString const,
PSafePtr<SIPHandler, PSafePtrBase> >, std::_Select1st<std::pair<PString
const, PSafePtr<SIPHandler, PSafePtrBase> > >, std::less<PString>,
std::allocator<std::pair<PString const, PSafePtr<SIPHandler,
PSafePtrBase> > > >::_M_destroy_node (this=0xb540f82c, __p=0xb541bb08)
at /usr/include/c++/4.3/bits/stl_tree.h:390
#10 0xb74191ac in std::_Rb_tree<PString, std::pair<PString const,
PSafePtr<SIPHandler, PSafePtrBase> >, std::_Select1st<std::pair<PString
const, PSafePtr<SIPHandler, PSafePtrBase> > >, std::less<PString>,
std::allocator<std::pair<PString const, PSafePtr<SIPHandler,
PSafePtrBase> > > >::erase (
    this=0xb540f82c, __position=...) at /usr/include/c
++/4.3/bits/stl_tree.h:1319
#11 0xb74191e6 in std::map<PString, PSafePtr<SIPHandler, PSafePtrBase>,
std::less<PString>, std::allocator<std::pair<PString const,
PSafePtr<SIPHandler, PSafePtrBase> > > >::erase (this=0xb540f82c,
__position=...) at /usr/include/c++/4.3/bits/stl_map.h:523
#12 0xb740c19f in SIPHandlersList::Remove (this=0xb540f748,
handler=0x825b288)
at /home/damien/Workspace/ekiga/opal/src/sip/handlers.cxx:1650
#13 0xb73c8637 in SIPEndPoint::GarbageCollection (this=0xb540f450)
at /home/damien/Workspace/ekiga/opal/src/sip/sipep.cxx:378
#14 0xb6f7e38e in OpalManager::GarbageCollection (this=0x82094d0)
at /home/damien/Workspace/ekiga/opal/src/opal/manager.cxx:1587
#15 0xb6f7e454 in OpalManager::GarbageMain (this=0x82094d0)
at /home/damien/Workspace/ekiga/opal/src/opal/manager.cxx:1607
#16 0xb6f8665b in OpalManager::GarbageMain_PNotifier::Call
(this=0x820bf28, note=..., extra=0)
    at /home/damien/Workspace/ekiga/opal/include/opal/manager.h:1452
#17 0xb7f19667 in PNotifierTemplate<int>::operator() (this=0x8208ca8,
notifier=..., extra=0) at /usr/include/ptlib/notifier.h:129
#18 0xb6a9eef9 in PSimpleThread::Main (this=0x8208c08) at
ptlib/common/osutils.cxx:1964
#19 0xb6a5cd1a in PThread::PX_ThreadStart (arg=0x8208c08) at
ptlib/unix/tlibthrd.cxx:459
#20 0xb673d4b5 in start_thread () from /lib/i686/cmov/libpthread.so.0
#21 0xb6381a5e in clone () from /lib/i686/cmov/libc.so.6


I get it by simply disabling an account.

--
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras@...
                       

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Damien Sandras wrote:

> Le mardi 13 octobre 2009 à 20:19 +0200, Damien Sandras a écrit :
>> Le mardi 13 octobre 2009 à 19:26 +0200, Michael Rickmann a écrit :
>>> Julien Puydt schrieb:
>>>> Julien Puydt a écrit :
>>>>> I had a nice surprise this morning, trying to launch ekiga :
>>>>> I'll try to update my ptlib&opal to see if I have just been unlucky.
>>>> I retried this evening : still crashing :-(
>>>>
>>>> Snark
>>>> _______________________________________________
>>> I tried this evening on WIN32 : still crashing.
>>> I guess we will have to exercise patience.
>>> I made shure that the reason for the crash is mainly in Opal's
>>> handlers.cxx index maps and not in Ekiga's heap. With attached patch
>>> Ekiga works.
>> I'll insist with Robert, but currently he does not answer me anymore.
>>
>
> Is this your crash :
> (gdb) bt
> #0  0xb6f7d44f in __exchange_and_add (__mem=0xb521ab02, __val=-1)
> at /usr/include/c++/4.3/ext/atomicity.h:51
> #1  0xb6f8cc3b in PAtomicInteger::operator-- (this=0xb521ab02)
> at /usr/include/ptlib/critsec.h:248
> #2  0xb6ac0dfb in PContainer::Destruct (this=0xb541bb18) at
> ptlib/common/contain.cxx:123
> #3  0xb7f19e8d in ~PAbstractArray (this=0xb541bb18, __in_chrg=<value
> optimized out>) at /usr/include/ptlib/array.h:69
> #4  ~PBaseArray (this=0xb541bb18, __in_chrg=<value optimized out>)
> at /usr/include/ptlib/array.h:271
> #5  ~PCharArray (this=0xb541bb18, __in_chrg=<value optimized out>)
> at /usr/include/ptlib/array.h:564
> #6  ~PString (this=0xb541bb18, __in_chrg=<value optimized out>)
> at /usr/include/ptlib/pstring.h:102
> #7  0xb73cf93d in ~pair (this=0xb541bb18, __in_chrg=<value optimized
> out>) at /usr/include/c++/4.3/bits/stl_pair.h:73
> #8  0xb73cf961 in __gnu_cxx::new_allocator<std::pair<PString const,
> PSafePtr<SIPHandler, PSafePtrBase> > >::destroy (this=0xb555013f,
> __p=0xb541bb18)
>     at /usr/include/c++/4.3/ext/new_allocator.h:118
> #9  0xb73cf9a5 in std::_Rb_tree<PString, std::pair<PString const,
> PSafePtr<SIPHandler, PSafePtrBase> >, std::_Select1st<std::pair<PString
> const, PSafePtr<SIPHandler, PSafePtrBase> > >, std::less<PString>,
> std::allocator<std::pair<PString const, PSafePtr<SIPHandler,
> PSafePtrBase> > > >::_M_destroy_node (this=0xb540f82c, __p=0xb541bb08)
> at /usr/include/c++/4.3/bits/stl_tree.h:390
> #10 0xb74191ac in std::_Rb_tree<PString, std::pair<PString const,
> PSafePtr<SIPHandler, PSafePtrBase> >, std::_Select1st<std::pair<PString
> const, PSafePtr<SIPHandler, PSafePtrBase> > >, std::less<PString>,
> std::allocator<std::pair<PString const, PSafePtr<SIPHandler,

My crash has _Rb_tree inside, as shown above in #10, I think it's the same.

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Michael Rickmann]

Damien Sandras schrieb:

> Le mardi 13 octobre 2009 à 20:19 +0200, Damien Sandras a écrit :
>> Le mardi 13 octobre 2009 à 19:26 +0200, Michael Rickmann a écrit :
>>> Julien Puydt schrieb:
>>>> Julien Puydt a écrit :
>>>>> I had a nice surprise this morning, trying to launch ekiga :
>>>>> I'll try to update my ptlib&opal to see if I have just been unlucky.
>>>> I retried this evening : still crashing :-(
>>>>
>>>> Snark
>>>> _______________________________________________
>>> I tried this evening on WIN32 : still crashing.
>>> I guess we will have to exercise patience.
>>> I made shure that the reason for the crash is mainly in Opal's
>>> handlers.cxx index maps and not in Ekiga's heap. With attached patch
>>> Ekiga works.
>> I'll insist with Robert, but currently he does not answer me anymore.
>>
>
> Is this your crash :
> (gdb) bt
> #0  0xb6f7d44f in __exchange_and_add (__mem=0xb521ab02, __val=-1)
> at /usr/include/c++/4.3/ext/atomicity.h:51
> #1  0xb6f8cc3b in PAtomicInteger::operator-- (this=0xb521ab02)
> at /usr/include/ptlib/critsec.h:248
> #2  0xb6ac0dfb in PContainer::Destruct (this=0xb541bb18) at
> ptlib/common/contain.cxx:123
> #3  0xb7f19e8d in ~PAbstractArray (this=0xb541bb18, __in_chrg=<value
> optimized out>) at /usr/include/ptlib/array.h:69
> #4  ~PBaseArray (this=0xb541bb18, __in_chrg=<value optimized out>)
> at /usr/include/ptlib/array.h:271
> #5  ~PCharArray (this=0xb541bb18, __in_chrg=<value optimized out>)
> at /usr/include/ptlib/array.h:564
> #6  ~PString (this=0xb541bb18, __in_chrg=<value optimized out>)
> at /usr/include/ptlib/pstring.h:102
> #7  0xb73cf93d in ~pair (this=0xb541bb18, __in_chrg=<value optimized
> out>) at /usr/include/c++/4.3/bits/stl_pair.h:73
> #8  0xb73cf961 in __gnu_cxx::new_allocator<std::pair<PString const,
> PSafePtr<SIPHandler, PSafePtrBase> > >::destroy (this=0xb555013f,
> __p=0xb541bb18)
>     at /usr/include/c++/4.3/ext/new_allocator.h:118
> #9  0xb73cf9a5 in std::_Rb_tree<PString, std::pair<PString const,
> PSafePtr<SIPHandler, PSafePtrBase> >, std::_Select1st<std::pair<PString
> const, PSafePtr<SIPHandler, PSafePtrBase> > >, std::less<PString>,
> std::allocator<std::pair<PString const, PSafePtr<SIPHandler,
> PSafePtrBase> > > >::_M_destroy_node (this=0xb540f82c, __p=0xb541bb08)
> at /usr/include/c++/4.3/bits/stl_tree.h:390
> #10 0xb74191ac in std::_Rb_tree<PString, std::pair<PString const,
> PSafePtr<SIPHandler, PSafePtrBase> >, std::_Select1st<std::pair<PString
> const, PSafePtr<SIPHandler, PSafePtrBase> > >, std::less<PString>,
> std::allocator<std::pair<PString const, PSafePtr<SIPHandler,
> PSafePtrBase> > > >::erase (
>     this=0xb540f82c, __position=...) at /usr/include/c
> ++/4.3/bits/stl_tree.h:1319
> #11 0xb74191e6 in std::map<PString, PSafePtr<SIPHandler, PSafePtrBase>,
> std::less<PString>, std::allocator<std::pair<PString const,
> PSafePtr<SIPHandler, PSafePtrBase> > > >::erase (this=0xb540f82c,
> __position=...) at /usr/include/c++/4.3/bits/stl_map.h:523
> #12 0xb740c19f in SIPHandlersList::Remove (this=0xb540f748,
> handler=0x825b288)
> at /home/damien/Workspace/ekiga/opal/src/sip/handlers.cxx:1650
> #13 0xb73c8637 in SIPEndPoint::GarbageCollection (this=0xb540f450)
> at /home/damien/Workspace/ekiga/opal/src/sip/sipep.cxx:378
> #14 0xb6f7e38e in OpalManager::GarbageCollection (this=0x82094d0)
> at /home/damien/Workspace/ekiga/opal/src/opal/manager.cxx:1587
> #15 0xb6f7e454 in OpalManager::GarbageMain (this=0x82094d0)
> at /home/damien/Workspace/ekiga/opal/src/opal/manager.cxx:1607
> #16 0xb6f8665b in OpalManager::GarbageMain_PNotifier::Call
> (this=0x820bf28, note=..., extra=0)
>     at /home/damien/Workspace/ekiga/opal/include/opal/manager.h:1452
> #17 0xb7f19667 in PNotifierTemplate<int>::operator() (this=0x8208ca8,
> notifier=..., extra=0) at /usr/include/ptlib/notifier.h:129
> #18 0xb6a9eef9 in PSimpleThread::Main (this=0x8208c08) at
> ptlib/common/osutils.cxx:1964
> #19 0xb6a5cd1a in PThread::PX_ThreadStart (arg=0x8208c08) at
> ptlib/unix/tlibthrd.cxx:459
> #20 0xb673d4b5 in start_thread () from /lib/i686/cmov/libpthread.so.0
> #21 0xb6381a5e in clone () from /lib/i686/cmov/libc.so.6
>
>
> I get it by simply disabling an account.
>

The middle portions look identical in the Win32 on-startup crash, i.e.
from #18 to #12. I just rebuild a crashing version to make absolutely shure.
Could there be another problem? When you look at
opal/src/sip/handlers.cxx:1689 FindBy(m_byAorAndPackage, MakeUrlKey(aor,
method), mode); . As no event package is given that FindBy will only
find handlers entered without event package. It is the simpler version
of the SIPHandlersList::FindSIPHandlerByUrl function and is called e.g.
from opal/src/sip/sipep.cxx:948 (in SIPEndPoint::Register) and others in
that file. Before revision 23623 to Opal which contained the m_byAOR map
these calls were always satisfied. Hopefully it will work now as well.
Now the backtrace of the on-startup crash is ready:

(gdb) #0  0x059924e2 in std::_Rb_tree_rebalance_for_erase ()
     at /home/mrickma/src/ekiga/win32/include/ptlib/videoio.h:1077
#1  0x059786bd in std::_Rb_tree<PString, std::pair<PString const,
PSafePtr<SIPHandler, PSafePtrBase> >, std::_Select1st<std::pair<PString
const, PSafePtr<SIPHandler, PSafePtrBase> > >, std::less<PString>,
std::allocator<std::pair<PString const, PSafePtr<SIPHandler,
PSafePtrBase> > > >::erase (this=0xc238fc0,
     __position={_M_node = 0xe6a3508})
     at
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/bits/stl_tree.h:1247
#2  0x059671dd in std::map<PString, PSafePtr<SIPHandler, PSafePtrBase>,
std::less<PString>, std::allocator<std::pair<PString const,
PSafePtr<SIPHandler, PSafePtrBase> > > >::erase (this=0xc238fc0,
__position={_M_node = 0xe6a3508})
     at
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/bits/stl_map.h:454
#3  0x057b1041 in SIPHandlersList::Remove (this=0xc238ed8,
handler=0xe6c60d8)
     at /home/mrickma/src/ekiga/win32/opal/src/sip/handlers.cxx:1650
#4  0x05783727 in SIPEndPoint::GarbageCollection (this=0xc238bb8)
     at /home/mrickma/src/ekiga/win32/opal/src/sip/sipep.cxx:378
#5  0x054e2b11 in OpalManager::GarbageCollection (this=0xc231e08)
     at /home/mrickma/src/ekiga/win32/opal/src/opal/manager.cxx:1587
#6  0x054e2bc4 in OpalManager::GarbageMain (this=0xc231e08)
     at /home/mrickma/src/ekiga/win32/opal/src/opal/manager.cxx:1607
#7  0x058b0e90 in OpalManager::GarbageMain_PNotifier::Call (this=0xc236848,
     note=@0xc232918, extra=0)
     at /home/mrickma/src/ekiga/win32/opal/include/opal/manager.h:1460
#8  0x045cffd6 in PNotifierTemplate<int>::operator() (this=0xc232970,
     notifier=@0xc232918, extra=0)
     at /home/mrickma/src/ekiga/win32/ptlib/include/ptlib/notifier.h:129
#9  0x04565fb3 in PSimpleThread::Main (this=0xc232918)
     at ptlib/common/osutils.cxx:1964
#10 0x04534886 in PThread::MainFunction (threadPtr=0xc232918)
     at ptlib/msos/win32.cxx:722
#11 0x77c0a3b0 in msvcrt!_endthreadex () from C:\WINDOWS\system32\msvcrt.dll
#12 0x7c80b683 in KERNEL32!GetModuleFileNameA ()
    from C:\WINDOWS\system32\kernel32.dll
#13 0x00000000 in ?? ()

My #9 to #3 correspond to your #18 to #12 with only #7/#16 having a line
mutation. Regarding the different Os and the different starting point I
would call it a highly conserved crash domain.
Michael
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Michael Rickmann]

Damien Sandras schrieb:

> Le mardi 13 octobre 2009 à 19:26 +0200, Michael Rickmann a écrit :
>> Julien Puydt schrieb:
>>> Julien Puydt a écrit :
>>>> I had a nice surprise this morning, trying to launch ekiga :
>>>> I'll try to update my ptlib&opal to see if I have just been unlucky.
>>> I retried this evening : still crashing :-(
>>>
>>> Snark
>>> _______________________________________________
>> I tried this evening on WIN32 : still crashing.
>> I guess we will have to exercise patience.
>> I made shure that the reason for the crash is mainly in Opal's
>> handlers.cxx index maps and not in Ekiga's heap. With attached patch
>> Ekiga works.
>
> I'll insist with Robert, but currently he does not answer me anymore.
>

I guess we interrupted Robert's workflow. I trust in his expertise.
Things may be more complicated than we can imagine.
Michael

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Damien Sandras]

Le mardi 13 octobre 2009 à 23:48 +0200, Michael Rickmann a écrit :

> Damien Sandras schrieb:
> > Le mardi 13 octobre 2009 à 19:26 +0200, Michael Rickmann a écrit :
> >> Julien Puydt schrieb:
> >>> Julien Puydt a écrit :
> >>>> I had a nice surprise this morning, trying to launch ekiga :
> >>>> I'll try to update my ptlib&opal to see if I have just been unlucky.
> >>> I retried this evening : still crashing :-(
> >>>
> >>> Snark
> >>> _______________________________________________
> >> I tried this evening on WIN32 : still crashing.
> >> I guess we will have to exercise patience.
> >> I made shure that the reason for the crash is mainly in Opal's
> >> handlers.cxx index maps and not in Ekiga's heap. With attached patch
> >> Ekiga works.
> >
> > I'll insist with Robert, but currently he does not answer me anymore.
> >
> I guess we interrupted Robert's workflow. I trust in his expertise.
> Things may be more complicated than we can imagine.

That's right. They have a lot of work and receiving many emails breaks
their concentration. But I think he fixed it.

--
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras@...
                       

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list