Bug 139447 - Crash when dragging a query or table from "Data Sources Explorer" window to a calc sheet.
Summary: Crash when dragging a query or table from "Data Sources Explorer" window to a...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.1.0.1 rc
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.2.0 target:7.1.5
Keywords: haveBacktrace, regression
: 143454 143724 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-01-06 12:21 UTC by Pinco Pallino
Modified: 2021-08-04 20:43 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
gdbtrace.log (13.62 KB, text/plain)
2021-01-09 13:28 UTC, Pinco Pallino
Details
bt with debug symbols (14.88 KB, text/plain)
2021-06-10 13:12 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pinco Pallino 2021-01-06 12:21:54 UTC
Description:
As soon as one tries to drag a query or table from the left "Explorer" section of the  "Data Sources" window into the sheet below the program crashes completely.

Steps to Reproduce:
1.In the menu choose "View"-"Data Sources" to open the "Data Sources" window/section above the current calc sheet.
2.In the "Explorer" on the left side of the window click on a registered database to reveal existing queries and tables. Click on a query or table to select it. 
3.Click and drag the selected table/query towardas the sheet below to import it as a "Database range".

Actual Results:
The program crashes completely. The request for sending a crash report comes up.
In bash console the following lines are printed:

qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 926, resource id: 31708960, major code: 40 (TranslateCoords), minor code: 0


Expected Results:
The selected query/table should have been imported into the sheet as a "Database Range".


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Open CL not used.
Comment 1 Pinco Pallino 2021-01-06 12:23:41 UTC
About Libreoffice:

Version: 7.1.0.1
Build ID: b585d7d90ab863bf29b2d110c174c0c2a98f3ee4
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kf5
Locale: es-ES (es_ES.UTF-8); UI: en-US
Calc: threaded
Comment 2 m_a_riosv 2021-01-06 18:20:18 UTC
No crash here.
Version: 7.1.0.1 (x64)
Build ID: b585d7d90ab863bf29b2d110c174c0c2a98f3ee4
CPU threads: 4; OS: Windows 10.0 Build 20180; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: es-ES Calc: CL
Comment 3 Julien Nabet 2021-01-06 19:23:48 UTC
It may be KDE specific.
Could you give a try at this:
- open a terminal/console
- export SAL_USE_VCLPLUGIN=gen && soffice --calc
give it a new try.
Comment 4 Pinco Pallino 2021-01-07 10:44:06 UTC
As suggested tried with "export SAL_USE_VCLPLUGIN=gen && soffice --calc".
The bug is still there: the program crashes immediately.
The only difference is that no error messages are printed in bash console.

Version: 7.1.0.1
Build ID: b585d7d90ab863bf29b2d110c174c0c2a98f3ee4
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: x11
Locale: es-ES (es_ES.UTF-8); UI: en-US
Calc: threaded
Comment 5 QA Administrators 2021-01-08 04:21:19 UTC Comment hidden (obsolete)
Comment 6 Julien Nabet 2021-01-09 10:44:50 UTC
Just to be sure, it's not due to a buggy profile or pb related to graphic driver, could you apply this https://wiki.documentfoundation.org/QA/FirstSteps ?

If you still reproduce the crash, it could be interesting to retrieve a backtrace with gen rendering (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace)
Comment 7 Pinco Pallino 2021-01-09 13:28:43 UTC
Created attachment 168790 [details]
gdbtrace.log

As requested by Julien Nabet
Comment 8 Pinco Pallino 2021-01-09 13:31:25 UTC
I have applied the recommendations of  https://wiki.documentfoundation.org/QA/FirstSteps.

Using a completely new user profile the bug is still there and LibreOffice crashes.

Sended separately the gdbtrace.log.

Version: 7.1.0.1
Build ID: b585d7d90ab863bf29b2d110c174c0c2a98f3ee4
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: x11
Locale: es-ES (es_ES.UTF-8); UI: en-US
Calc: threaded
Comment 9 Julien Nabet 2021-01-09 16:34:18 UTC
On what Linux distrib are you?
Did you install 7.1.0.1 RC from repository of your distrib or did you download packages from official LO TDF?
You must know that Linux packages from official LO TDF are more for distrib maintainers. Indeed there are dependencies which must dealt with.
So if you install these, you should uninstall 7.1.0.1 RC and install LO from the repository of your distrib (+ clean your LO profile).
Comment 10 Robert Großkopf 2021-06-09 18:20:56 UTC
Same buggy behavior here with LO 7.1.4.2 on OpenSUSE 15.2 64bit rpm Linux. Deleting the user-profile doesn't help here.

Note: Try to drag a table from the left of the datasource-browser. Left Mouseclick on "biblio", the table of the database "Bibliography". When I try to start dragging the table LO crashes immediately.

This bug doesn't appear in LO 7.0.5.2 on the same machine.
Comment 11 Daniele 2021-06-10 13:02:24 UTC
I tested this bug on Windows 10 and MacOS Big Sur. 
Libreoffice 7.1.4 crashes every time I drag a table/query from data sources to a Calc cell. 
Libreoffice 7.0.6 works fine.
Comment 12 Julien Nabet 2021-06-10 13:12:05 UTC
Created attachment 172770 [details]
bt with debug symbols

Thank you Robert for your feedback.
I could reproduce the crash on pc Debian x86-64 with master sources updated today with gen rendering.
I can reproduce this too with gtk3.
Comment 13 Julien Nabet 2021-06-10 17:01:49 UTC
Caolán: I tried to understand the crash with the bt but for a reason I ignore, m_sCompatibleObjectDescription is unreadable whereas m_aDescriptor is ok:

here's the output of p this:
{<TransferDataContainer> = {<TransferableHelper> = {<cppu::WeakImplHelper<com::sun::star::datatransfer::XTransferable2, com::sun::star::datatransfer::clipboard::XClipboardOwner, com::sun::star::datatransfer::dnd::XDragSourceListener, com::sun::star::lang::XUnoTunnel>> = {<cppu::OWeakObject> = {<com::sun::star::uno::XWeak> = {<com::sun::star::uno::XInterface> = {
              _vptr$XInterface = 0x7f44374ccb20 <vtable for svx::OComponentTransferable+16>}, <No data fields>}, m_refCount = 3, m_pWeakConnectionPoint = 0x0, 
          m_pReserved = 0x0}, <com::sun::star::lang::XTypeProvider> = {<com::sun::star::uno::XInterface> = {
            _vptr$XInterface = 0x7f44374ccc00 <vtable for svx::OComponentTransferable+240>}, <No data fields>}, <com::sun::star::datatransfer::XTransferable2> = {<com::sun::star::datatransfer::XTransferable> = {<com::sun::star::uno::XInterface> = {
              _vptr$XInterface = 0x7f44374ccc38 <vtable for svx::OComponentTransferable+296>}, <No data fields>}, <No data fields>}, <com::sun::star::datatransfer::clipboard::XClipboardOwner> = {<com::sun::star::uno::XInterface> = {
            _vptr$XInterface = 0x7f44374ccc88 <vtable for svx::OComponentTransferable+376>}, <No data fields>}, <com::sun::star::datatransfer::dnd::XDragSourceListener> = {<com::sun::star::lang::XEventListener> = {<com::sun::star::uno::XInterface> = {
              _vptr$XInterface = 0x7f44374cccb8 <vtable for svx::OComponentTransferable+424>}, <No data fields>}, <No data fields>}, <com::sun::star::lang::XUnoTunnel> = {<com::sun::star::uno::XInterface> = {
            _vptr$XInterface = 0x7f44374ccd10 <vtable for svx::OComponentTransferable+512>}, <No data fields>}, <No data fields>}, maAny = uno::Any(void), maLastFormat = "", mxClipboard = empty uno::Reference, 
      mxTerminateListener = empty uno::Reference, maFormats = std::__debug::vector of length 0, capacity 1, mxObjDesc = std::unique_ptr<TransferableObjectDescriptor> = {get() = 0x0}}, 
    pImpl = std::unique_ptr<TransferDataContainer_Impl> = {get() = 0x47e3950}}, m_aDescriptor = {m_pImpl = std::unique_ptr<svx::ODADescriptorImpl> = {get() = 0x47e39d0}}, 
  m_sCompatibleObjectDescription = <error reading variable: Cannot access memory at address 0x99999999999999e8>}

I tried to trace where ctr with some fprintf(sterr, but nothing.
Comment 14 Caolán McNamara 2021-06-10 19:34:31 UTC
with 
m_sCompatibleObjectDescription = <error reading variable: Cannot access memory at address 0x99999999999999e8>
I bet that parent object is not really the type is has been cast to
Comment 15 Commit Notification 2021-06-11 08:17:50 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3c325bd525d7726395db733e684b84b1659bd41a

tdf#139447 crash on dragging query/table from explorer to calc sheet

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 16 Caolán McNamara 2021-06-11 08:44:03 UTC
undoubtedly a regression of mine, done in trunk, backport to 7-1 in gerrit
Comment 17 Julien Nabet 2021-06-11 09:46:38 UTC
On pc Debian x86-64 with master sources updated today (including Caolán's fix), I confirm I don't reproduce the crash anymore.
I just wonder why m_aDescriptor seemed ok and m_sCompatibleObjectDescription obviously ko

Anyway, thank you Caolán! (as usual! :-))
Comment 18 Commit Notification 2021-06-11 10:20:28 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2e415a90958bb00f460dccb303bc22853244292b

Related: tdf#139447 DBTreeViewBase ctor takes a bool if its a sqltype or not

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 19 Commit Notification 2021-06-22 07:38:03 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/b0f7621fa53c20f4a74b82141d2ee03fcbd08578

tdf#139447 crash on dragging query/table from explorer to calc sheet

It will be available in 7.1.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 20 Julien Nabet 2021-07-21 19:31:19 UTC
*** Bug 143454 has been marked as a duplicate of this bug. ***
Comment 21 Julien Nabet 2021-08-04 20:43:10 UTC
*** Bug 143724 has been marked as a duplicate of this bug. ***