Bug 66706 - lifetime issue of DocumentBasicManager at exit of Base
Summary: lifetime issue of DocumentBasicManager at exit of Base
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
4.1.0.2 rc
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 66707 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-07-08 17:33 UTC by Lionel Elie Mamane
Modified: 2023-12-04 03:15 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
backtrace (77.06 KB, text/plain)
2013-07-08 17:33 UTC, Lionel Elie Mamane
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2013-07-08 17:33:46 UTC
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!!
Comment 1 Lionel Elie Mamane 2013-07-08 17:38:27 UTC
*** Bug 66707 has been marked as a duplicate of this bug. ***
Comment 2 Jorendc 2013-07-09 08:51:51 UTC
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
Comment 3 Noel Power 2013-07-12 07:40:10 UTC
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 ?
Comment 4 Lionel Elie Mamane 2013-07-12 10:16:25 UTC
(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!
Comment 5 Lionel Elie Mamane 2013-07-12 10:47:42 UTC
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.
Comment 6 Lionel Elie Mamane 2013-07-12 11:12:59 UTC
> 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.
Comment 7 Noel Power 2013-07-12 12:00:00 UTC
(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 :-(
Comment 8 Alex Thurgood 2015-01-03 17:40:34 UTC Comment hidden (no-value)
Comment 9 QA Administrators 2016-01-17 20:03:23 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2017-03-06 14:08:25 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2019-12-03 14:11:09 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2021-12-03 04:29:05 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2023-12-04 03:15:53 UTC
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