Created attachment 82195 [details] backtrace When exiting Base, I got a crash, which seems local to Basic code. Not systematically reproducible. Backtrace attached. Analysis #29 0x00007f226a93c553 in basic::ImplRepository::getDocumentBasicManager (this=0x2f44060, _rxDocumentModel=uno::Reference to (dbaccess::ODatabaseDocument *) 0x33e2370) at /home/master/src/libreoffice/workdirs/libreoffice-4.1/basic/source/basmgr/basicmanagerrepository.cxx:253 (gdb) list 251 BasicManagerPointer& pBasicManager = impl_getLocationForModel( _rxDocumentModel ); 252 if ( pBasicManager == NULL ) 253 impl_createManagerForModel( pBasicManager, _rxDocumentModel ); So it seems that here pBasicManager was NULL, and impl_createManagerForModel was called with its first argument being NULL initially. (gdb) down #28 0x00007f226a93dfad in basic::ImplRepository::impl_createManagerForModel (this=0x2f44060, _out_rpBasicManager=@0x3b9c848: 0x9999999999999999, _rxDocumentModel= uno::Reference to (dbaccess::ODatabaseDocument *) 0x33e2370) at /home/master/src/libreoffice/workdirs/libreoffice-4.1/basic/source/basmgr/basicmanagerrepository.cxx:497 (gdb) list 496 // register as listener for the BasicManager being destroyed 497 StartListening( *_out_rpBasicManager ); (gdb) print _out_rpBasicManager $5 = (basic::BasicManagerPointer &) @0x3b9c848: 0x9999999999999999 The first argument is 0x9999999999999999. From our MALLOC_PERTURB_=153 in ooenv, all 9's is the value that free()d/deleted memory gets. So it seems there is some lifetime issue, but from staring at the code, I don't guess where. impl_createManagerForModel should create a BasicManager and stick it in _out_rpBasicManager, but where would it be destroyed? Possibly the problem is actually (much) higher? Frame 39/40, I see the destructor of BasicManager; it seems suspicious to me that a new BasicManager is constructed from the destructor of the same type!!
*** Bug 66707 has been marked as a duplicate of this bug. ***
With a backtrace attached it is hard to deny there is no crash/issue :-). Hopefully it doesn't crash that often. If can reproduce it more often and can provide steps, please do :). Kind regards, Joren
lionel, is this easily reproducible? ( I tried on master, just opening some random odb and exiting but no luck ) what about valgrind, does it give anymore useful info? I have a feeling alot of that basic::ImplRepository stuff was introduce by Frank ( back in the day ) specifically for some issues relating to base ( but I could be very much mistaken ) Is there something special you know about base documents that would require that ?
(In reply to comment #3) > lionel, is this easily reproducible? ( I tried on master, just opening some > random odb and exiting but no luck ) I got a crash-at-exit again (with master), but got no backtrace ('ulimit -c' was 0...), and I cannot pin down specific instructions to make it reproducibly crash. From staring at the backtrace, I'd say it is related to the Basic IDE's Object Catalog: for each entry, it checks whether it should delete the entry or not. To do that, it calls HasMethod(), which tries to get the BasicManager, which implicitly creates it. My guess is that this is some kind of race condition between the document disappearing, the Basic manager disappearing, and the Object Catalog checking whether a specific Basic method is in the document. If this check happens after the Basic manager disappears, but before the whole document disappears, then this crash happens. When it does not crash, I get: warn:legacy.osl:23161:1:basic/source/basmgr/basicmanagerrepository.cxx:581: ImplRepository::_disposing: where does this come from? warn:legacy.osl:23161:1:basic/source/basmgr/basicmanagerrepository.cxx:581: ImplRepository::_disposing: where does this come from? On a crash (with unknown backtrace), I got warn:legacy.osl:21648:1:basctl/source/basicide/bastype2.cxx:687: TreeListBox::ExpandingHdl: no document, or document is dead!
In particular, I notice: basic/source/basmgr/basicmanagerrepository.cxx void ImplRepository::Notify: // a BasicManager which is still in our repository is being deleted. // That's bad, since by definition, we *own* all instances in our // repository. But in my backtrace, it is notifications dbaccess::ODatabaseDocument::dispose that lead to destruction of the BasicManager (frames 40 to 48). Oh, but this goes via ImplRepository so should be OK, except that m_aStore contains an *already* *deleted* BasicManager (value 0x9999999999999999999). Grrr... This is confusing. At time of entrance in the loop body, we had loop->first == xNormalizedSource.get (). But at the time of the crash, loop->first has been deleted... Ah, actually this makes sense, since impl_removeFromRepository has called m_aStore.erase( loop )... I don't see any mutex in basicmanagerrepository; could this be a reentrency issue where one thread deletes the BasicManager under the feet of the other thread? I wonder if the "if ( !isValid() )" in criptDocument::Impl::getBasicManager should not be "if ( !isAlive() )"... OTOH, in the trace, we see "m_bDocumentClosed = false". Raaah... I'm getting lost.
> I have a feeling alot of that basic::ImplRepository stuff was introduce by > Frank ( back in the day ) specifically for some issues relating to base ( > but I could be very much mistaken ) Is there something special you know > about base documents that would require that ? Possibly you are thinking of the CreationListener stuff that is used by (and may plausibly have been created for) dbaccess/source/core/dataaccess/databasecontext.cxx to install the global "ThisDatabaseDocument" variable in scope.
(In reply to comment #4) > (In reply to comment #3) > > lionel, is this easily reproducible? ( I tried on master, just opening some > > random odb and exiting but no luck ) > > I got a crash-at-exit again (with master), but got no backtrace ('ulimit -c' > was 0...), and I cannot pin down specific instructions to make it > reproducibly crash. > > From staring at the backtrace, I'd say it is related to the Basic IDE's > Object Catalog: for each entry, it checks whether it should delete the > entry or not. To do that, it calls HasMethod(), which tries to get the > BasicManager, which implicitly creates it. > > My guess is that this is some kind of race condition between the document > disappearing, the Basic manager disappearing, and the Object Catalog > checking whether a specific Basic method is in the document. If this check > happens after the Basic manager disappears, but before the whole document > disappears, then this crash happens. > > When it does not crash, I get: > warn:legacy.osl:23161:1:basic/source/basmgr/basicmanagerrepository.cxx:581: > ImplRepository::_disposing: where does this come from? > warn:legacy.osl:23161:1:basic/source/basmgr/basicmanagerrepository.cxx:581: > ImplRepository::_disposing: where does this come from? > > On a crash (with unknown backtrace), I got > > warn:legacy.osl:21648:1:basctl/source/basicide/bastype2.cxx:687: > TreeListBox::ExpandingHdl: no document, or document is dead! I would be suspicious of this stuff also, I have seen some funny messages on exit before regarding this ( and on my todo to look at ) Unfortunately ObjectCatalog seems to have a raft of behaviour problems ( most recently a huge performance hit ) but not limited to that :-(
Adding self to CC if not already on
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.