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
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT: - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-01-17
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
Dear Lionel Elie Mamane, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Lionel Elie Mamane, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug