Download it now!
Bug 137745 - LO Base Firebird: crash, when deleting tables and changed relationship isn't changed in database file
Summary: LO Base Firebird: crash, when deleting tables and changed relationship isn't ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.3.5.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Julien Nabet
URL:
Whiteboard: target:7.2.0 target:7.1.0.0.beta2 tar...
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-25 19:29 UTC by Richard Demattio
Modified: 2020-12-02 10:39 UTC (History)
4 users (show)

See Also:
Crash report or crash signature: 57e87d4b-1115-4522-8a19-d6c2631f5859


Attachments
Testcase Database (58.36 KB, application/octet-stream)
2020-10-25 19:43 UTC, Richard Demattio
Details
backtrace from call indirect through 0x0 (10.38 KB, text/plain)
2020-10-27 15:21 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Demattio 2020-10-25 19:29:59 UTC
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
Comment 1 Richard Demattio 2020-10-25 19:43:37 UTC
Created attachment 166710 [details]
Testcase Database
Comment 2 Robert Großkopf 2020-10-26 11:09:01 UTC
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.
Comment 3 Richard Demattio 2020-10-26 21:50:17 UTC
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
Comment 4 Richard Demattio 2020-10-26 22:05:57 UTC
(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.
Comment 5 Robert Großkopf 2020-10-27 06:57:44 UTC
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.
Comment 6 Robert Großkopf 2020-10-27 07:03:39 UTC
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.
Comment 7 Terrence Enger 2020-10-27 15:21:18 UTC
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.
Comment 8 Julien Nabet 2020-11-26 22:12:05 UTC
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.
Comment 9 Commit Notification 2020-11-27 18:09:11 UTC
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.
Comment 10 Julien Nabet 2020-11-27 18:17:05 UTC
Backports waiting for review here:
- https://gerrit.libreoffice.org/c/core/+/106742 (7.1)
- https://gerrit.libreoffice.org/c/core/+/106743 (7.0)
Comment 11 Commit Notification 2020-11-27 22:02:34 UTC
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.
Comment 12 Commit Notification 2020-11-28 08:08:51 UTC
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.
Comment 13 Commit Notification 2020-12-01 09:20:18 UTC
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.