Description: Details: see Attachments The crash is reproducable, when CALC and Base are open. The tables are in relation by foreign keys and I created them via SQL input. Steps to Reproduce: 1.Start CALC 2. open the database (attached testcase "testEnv.odb") 3. delete tables from bottom up 3.a. Vertragspositionen 3.b. Verträge 3.c. Parzellen (without saving after each step) The crash does NOT happen, when I save between each step The crash does not happen too, when only BASE is running. I could also reproduce it with build Version=7.1.0.0 BuildID=17cbc559be6936777904e5cf8a517cac89045264 (see attachment) Actual Results: crash Expected Results: no crash and the deletions should be done or rejected, if there are good reasons Reproducible: Always User Profile Reset: No Additional Info: see also crashreport.libreoffice.org/stats/crash_details/57e87d4b-1115-4522-8a19-d6c2631f5859
Created attachment 166710 [details] Testcase Database
Tested it with opening a Calc-document, opening the database and deleting all tables in the database without saving. Could not reproduce a crash here. Tested with LO 7.0.3.1 and OpenSUSE 15.1 64bit rpm Linux.
Now I upgraded to 7.0.1.3 too and repeated the test. This version is indeed increased stability. BUT I could provoke the crash by doing the following: 1.) I opened an empty CALC spreadsheet and entered one value there 2.) I opened the database, attached here 3.) I went to "Tools/Relationships" and moved some of the Tables 4.) I saved the changed Relationship graphic 5.) I started deleting the tables and crashed
(Additional Info to comment #3) First of all: the good thing is, that the data is not lost I repeated the test once more with the same result. But I recognized the following: After step 4 of my last comment (saving the changed relationship) I recognized, that the "save icon" in the tool bar remained in status "red". After completing the saving by this button, LO base is stable again.
Now I could reproduce the crash: 1) Opened a new Calc document 2) Type in A1 "1" and won't save it 3) Opened the attached database 4) Tools → Relationship and moved the tables a little bit. 5) Saved relationship 6) Deleted the first table 7) Deleted the second table → Crash appears Tried this a second time with the same behavior. Note: LO will restore database relationship and Calc table to the changes I made. Will show all tables in the database. No table has been deleted. Hint: Saving something inside a database file won't be saved automatically in the file. You have to press the save button of Base also, if you change the relationship, create a form, change a report ... Crash appears with LO 7.0.3.1 on OpenSUSE 15.1 64bit rpm Linux. Crash appears also with LO 6.4.6.2 and LO 6.3.5.2 Set the version to the oldest version to reflect this. Seems it isn't a new regression of LO 7.0. All crashes with the Firebird database.
Have tested it a little bit more: Has nothing to do with Calc. 1) Open the database. 2) Tools → Relationship 3) Move the tables and save inside the relationship window 4) Don't save the database file 5) Delete tables When I try to delete the second table it crashes. I changed the title to reflect this.
Created attachment 166782 [details] backtrace from call indirect through 0x0 I followed the steps of comment 6. For specificity: - at step 4), the program prompted "... save changes?". I clicked <No>. - at step 6), I deleted tables in the order of comment 0 step 3. The crash happened at step 3.b., delete table Verträge. This observation is from a local build of commit 5219c6bd (2020-10-24), built and running on debian-buster. From the backtrace (rewrapped): #14 0x00007f781b204a57 in (anonymous namespace)::OTableContainerListener::elementRemoved (com::sun::star::container::ContainerEvent const&) (this=0x5581da160750, Event=...) at /home/terry/lo_hacking/git/libo6/ connectivity/source/commontools/TTableHelper.cxx:78 That source line reads: m_pComponent->refreshKeys(); m_pComponent is 0x0. I am adding keyword haveBacktrace.
On pc Debian x86-64 with master sources updated today, I could reproduce this. After having put a break in: OTableContainerListener::clear() at connectivity/source/commontools/TTableHelper.cxx:96 and OTableContainerListener::elementRemoved(com::sun::star::container::ContainerEvent const&) at connectivity/source/commontools/TTableHelper.cxx:77 I began to delete tables and found these: #0 (anonymous namespace)::OTableContainerListener::clear() (this=0x41a3800) at connectivity/source/commontools/TTableHelper.cxx:96 #1 0x00007f786b1e39ba in connectivity::OTableHelper::disposing() (this=0x57f6ac0) at connectivity/source/commontools/TTableHelper.cxx:186 #2 0x00007f78772fd3b3 in cppu::WeakComponentImplHelperBase::dispose() (this=0x57f6af0) at cppuhelper/source/implbase.cxx:104 #3 0x00007f785a873f98 in cppu::PartialWeakComponentImplHelper<com::sun::star::sdbcx::XColumnsSupplier, com::sun::star::sdbcx::XKeysSupplier, com::sun::star::container::XNamed, com::sun::star::lang::XServiceInfo>::dispose() (this=0x57f6af0) at include/cppuhelper/compbase.hxx:90 #4 0x00007f786b221ab2 in comphelper::disposeComponent<com::sun::star::lang::XComponent>(com::sun::star::uno::Reference<com::sun::star::lang::XComponent>&) (_rxComp=uno::Reference to (connectivity::firebird::Table *) 0x57f6b10) at include/comphelper/types.hxx:48 #5 0x00007f786b2d89a6 in (anonymous namespace)::OHardRefMap<com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> >::disposeAndErase(int) (this=0x55f12d0, _nIndex=2) at connectivity/source/sdbcx/VCollection.cxx:162 #6 0x00007f786b2d62db in connectivity::sdbcx::OCollection::dropImpl(int, bool) (this=0x55dc2a0, _nIndex=2, _bReallyDrop=true) at connectivity/source/sdbcx/VCollection.cxx:418 ... #0 (anonymous namespace)::OTableContainerListener::elementRemoved(com::sun::star::container::ContainerEvent const&) (this=0x58cedd0, Event=...) at connectivity/source/commontools/TTableHelper.cxx:77 #1 0x00007f786b2d6709 in connectivity::sdbcx::OCollection::notifyElementRemoved(rtl::OUString const&) (this=0x55dc2a0, _sName="tmv_Verträge") at connectivity/source/sdbcx/VCollection.cxx:430 #2 0x00007f786b2d62ed in connectivity::sdbcx::OCollection::dropImpl(int, bool) (this=0x55dc2a0, _nIndex=2, _bReallyDrop=true) at connectivity/source/sdbcx/VCollection.cxx:421 ... Since elementRemoved was called after OTableContainerListener::clear() which puts m_pComponent to nullptr, we must check if m_pComponent is null before using it in elementRemoved.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4335810b00abb9b00a9d81caa5ffe09a3ea927fd tdf#137745: crash, when deleting tables and changed relationship isn't changed It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Backports waiting for review here: - https://gerrit.libreoffice.org/c/core/+/106742 (7.1) - https://gerrit.libreoffice.org/c/core/+/106743 (7.0)
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/5dae252e76da9c95049ba8124422a1f7b2f10596 tdf#137745: crash, when deleting tables and changed relationship isn't changed It will be available in 7.1.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/d9c84029c18ea0964705ed8c56e40784a1c556df tdf#137745: crash, when deleting tables and changed relationship isn't changed It will be available in 7.0.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-0-4": https://git.libreoffice.org/core/commit/b700cd9509895ade747d7cd5ee0b628307fb08de tdf#137745: crash, when deleting tables and changed relationship isn't changed It will be available in 7.0.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.