Bug 144072 - LibreOffice Base crashed when 2 fields selected in report builder from different sections and width is adjusted 2nd time
Summary: LibreOffice Base crashed when 2 fields selected in report builder from differ...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
7.0.6.2 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:24.2.0 target:7.6.1
Keywords: bibisectRequest, regression
: 145362 (view as bug list)
Depends on:
Blocks: Crash
  Show dependency treegraph
 
Reported: 2021-08-25 02:31 UTC by shodgman
Modified: 2023-09-19 06:44 UTC (History)
12 users (show)

See Also:
Crash report or crash signature: ["WinSalFrame::SetPointer(PointerStyle)"]


Attachments
Example LibreOffice Base object with report that crashes (7.03 KB, application/vnd.sun.xml.base)
2021-08-26 00:11 UTC, shodgman
Details
Apple Stack Trace produced on crash (140.24 KB, text/plain)
2021-08-26 09:31 UTC, Alex Thurgood
Details
Output from running in the Terminal (2.10 KB, text/plain)
2023-04-16 18:33 UTC, Patrick Luby
Details
Sample during crash when Recover Document dialog appears (155.06 KB, text/plain)
2023-04-16 20:15 UTC, Patrick Luby
Details

Note You need to log in before you can comment on or make changes to this bug.
Description shodgman 2021-08-25 02:31:05 UTC
Description:
In Report Builder GUI, EDITING a report, selected a Label and Data Field with shift-Click.  Adjusted width to be smaller smaller.
Then did it again and Libreoffice crashed.  This can be replicated.
Crash report
https://crashreport.libreoffice.org/stats/crash_details/72cead4d-c716-4290-8155-bd1d22adbe08
When restart

Steps to Reproduce:
1.Edit a report in LibreofficeBase  (Report in tabular form)
2.Select a Label and data field using shift-Click.
3.Reduce width of fields by selecting width of 1 and making selection narrower
4.Stop moving
5. Make narrower again as above


Actual Results:
Libreoffice crashes.
Recovery went back steps.

Expected Results:
Reduced width of fields


Reproducible: Always


User Profile Reset: No



Additional Info:
Crash report
https://crashreport.libreoffice.org/stats/crash_details/72cead4d-c716-4290-8155-bd1d22adbe08
Comment 1 Robert Großkopf 2021-08-25 06:09:58 UTC
Have tested it with a report here. Couldn't confirm the behavior. Could set the width smaller 2 times without any problem.

Could you attach an example with this buggy behavior? Write down also something about your system an the LO-version you are using.
Comment 2 Alex Thurgood 2021-08-25 14:23:37 UTC
@Robert : the system reported in the crash report uploaded by the OP is 

Windows OS 10.0.19043 

Seems to be a bug that is specific to Windows 

ImplHandleMouseEvent(VclPtr<vcl::Window> const &,MouseNotifyEvent,bool,__int64,__int64,unsigned __int64,unsigned short,MouseEventModifiers)

and

WinSalFrame::SetPointer(PointerStyle)
Comment 3 shodgman 2021-08-26 00:11:18 UTC
Created attachment 174542 [details]
Example LibreOffice Base object with report that crashes

Attached LibreOffice Base file created to demonstrate the bug.

Open Report RptTasks in Edit mode.
Select any field in the Detail part of report
Shift-Click the header label in the Header above this.
Select the handle to reduce in horizontal size
Attempt to reduce size.
For me Libreoffice Base then crashes.

I have only been developing in Base recently. Running 7.1.5.2 on Windows 10.
Sorry that I did not explain that the double selection needs to be across Header and Detail Sections of the report.  My testing shows that double selection works if all fields are in one report section.  If they are in different sections then it crashes very regularly, if not always.
Comment 4 Alex Thurgood 2021-08-26 09:29:56 UTC
For me, on macOS, any attempt to move any selected field+label causes an immediate crash with

Version: 7.2.0.4 / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

Enclosing Apple Stack Trace.
Comment 5 Alex Thurgood 2021-08-26 09:31:45 UTC
Created attachment 174550 [details]
Apple Stack Trace produced on crash
Comment 6 Xisco Faulí 2021-08-26 14:43:11 UTC
I can't reproduce it in

Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: fbe183bbb05220a4ccc51952445b1797bb498403
CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 7 Xisco Faulí 2021-08-26 14:44:32 UTC
Nor in

Version: 7.2.1.0.0+ / LibreOffice Community
Build ID: 5d6a91b8ea40ec79c746e5c1d486be6e25a2856d
CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 8 Xisco Faulí 2021-08-26 14:48:25 UTC
(In reply to Alex Thurgood from comment #4)
> For me, on macOS, any attempt to move any selected field+label causes an
> immediate crash with
> 
> Version: 7.2.0.4 / LibreOffice Community
> Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
> CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
> Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
> Calc: threaded
> 
> Enclosing Apple Stack Trace.

that is already reported in bug 144072. Putting this one back to UNCONFIRMED
Comment 9 shodgman 2021-08-27 04:40:12 UTC
Just downloaded 7.2.0.4 (Windows 10) and cannot reproduce the fault.
Seeing different behaviour now.
Thanks everyone for the support and for chasing it up.
Comment 10 shodgman 2021-08-27 05:20:25 UTC
I was Too Hasty - Still getting this behaviour in 7.2.0.4
Comment 11 Buovjaga 2021-08-27 10:23:05 UTC
Repro, but weirdly I can't repro in a gdb session.

Also, I can repro in the oldest of 7.1 bibisect repo, but not in the latest of 7.0 repo, so can't really bibisect.

Arch Linux 64-bit
Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 67879304f61252838a6b2e2549d7205b445776f8
CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 27 August 2021
Comment 12 Xisco Faulí 2021-10-28 14:04:32 UTC
Hi all,
I'm wondering whether it was fixed by the fix for bug 144564.
Could you please try again with LibreOffice 7.2.2.2?
Comment 13 Buovjaga 2021-10-28 14:32:26 UTC
No crash for me at least, hopefully others can verify as well

Arch Linux 64-bit
Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 6678b8123c9952c80a637d3a7f4e27511122009e
CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 27 October 2021
Comment 14 Xisco Faulí 2021-10-28 14:34:54 UTC
*** Bug 145362 has been marked as a duplicate of this bug. ***
Comment 15 Alex Thurgood 2021-10-28 14:46:40 UTC
No repro for me already with :

Version: 7.2.1.2 / LibreOffice Community
Build ID: 87b77fad49947c1441b67c559c339af8f3517e22
CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded
Comment 16 Buovjaga 2021-10-28 14:48:19 UTC
(In reply to Alex Thurgood from comment #15)
> No repro for me already with :
> 
> Version: 7.2.1.2 / LibreOffice Community
> Build ID: 87b77fad49947c1441b67c559c339af8f3517e22
> CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
> Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
> Calc: threaded

Then it must be some other fix than bug 144564
Comment 17 Aron Budea 2022-04-15 18:45:37 UTC
I'm able to reproduce it in LO 7.4.0.0.alpha0+ (ab612633003c75dfb30664db8cc8924c086a91ee) / Ubuntu.

I have to say, the UX of resizing those widgets is terrible, you try to drag from the right edge, and it resizes from the left, or from the corner. That's one of the reasons why the crash is hard to reproduce.
Comment 18 raal 2022-10-22 08:39:30 UTC
(In reply to Aron Budea from comment #17)
> I'm able to reproduce it in LO 7.4.0.0.alpha0+
> (ab612633003c75dfb30664db8cc8924c086a91ee) / Ubuntu.
> 
> I have to say, the UX of resizing those widgets is terrible, you try to drag
> from the right edge, and it resizes from the left, or from the corner.
> That's one of the reasons why the crash is hard to reproduce.

@Aron, can you bisect it?
Comment 19 Aron Budea 2022-10-23 03:57:44 UTC
(In reply to raal from comment #18)
> @Aron, can you bisect it?
I did get the crash after some steps based on the report, plus undoing changes, but the steps were anything but consistent, thus I'd rather not go down that rabbit hole.
Comment 20 Stéphane Guillou (stragu) 2023-03-02 11:55:44 UTC
(In reply to Xisco Faulí from comment #8)
> (In reply to Alex Thurgood from comment #4)
> > For me, on macOS, any attempt to move any selected field+label causes an
> > immediate crash with
> > 
> > Version: 7.2.0.4 / LibreOffice Community
> > Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
> > CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
> > Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
> > Calc: threaded
> > 
> > Enclosing Apple Stack Trace.
> 
> that is already reported in bug 144072. Putting this one back to UNCONFIRMED

I think that was supposed to be bug 88268, Xisco?

I found I could reproduce consistently by:
1) Selecting both header and details fields
2) Dragging slowly inward from bottom-right corner

I can reproduce on both Ubuntu 20.04 and Windows 10.
LO versions:

- 7.0.6.2
- 7.1.0.3
- 7.2.0.3
- 7.4.5.1
- 7.5.1.2

and a recent master build:

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5a235634ca5761aa4b330ebf7e3a2083b7db1606
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded

But not in:

Version: 6.4.7.2
Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
Calc: threaded

However, when I try to bibisect with the linux-64-7.0 repo, I can't reproduce the crash.
Comment 21 Patrick Luby 2023-04-16 14:38:46 UTC
I just noticed that the Apple Stack Trace in attachment 174550 [details] is crashing due to a native exception being thrown that is not caught. This is the same type of crash in issue 146626.

I will see if I can reproduce this bug in a debug build.
Comment 22 Patrick Luby 2023-04-16 18:08:04 UTC
(In reply to Patrick Luby from comment #21)
> I just noticed that the Apple Stack Trace in attachment 174550 [details] is
> crashing due to a native exception being thrown that is not caught. This is
> the same type of crash in issue 146626.
> 
> I will see if I can reproduce this bug in a debug build.

I can reproduce the crash in a debug build. However, I can no longer upload an attachment (tried in multiple browsers) so I'll summarize what I found here:

I can reproduce this bug. The mystery is which code is throwing the uncaught exception so I ran my debug build from the command line in a Terminal window and I got the output in the attached "libo.log" file.

The top of the file contains the following error messages and then is followed by a stack trace:

Assertion failed: (nNum <= std::numeric_limits<sal_Int32>::max( )), function Fraction, file fract.cxx, line 59.
Assertion failed: (nNum <= std::numeric_limits<sal_Int32>::max( )), function Fraction, file fract.cxx, line 59.

The stack trace shows at the point of crash (i.e. the _sigtramp call closest to the end of the file) shows the following function being called with bad values:

41  libtllo.dylib                       0x00000001039b5d68 _ZN8FractionC2Ell + 208
42  libtllo.dylib                       0x00000001039b636c _ZN8FractionC1Ell + 44
43  libsvxcorelo.dylib                  0x0000000111e5bc90 _ZNK11SdrDragStat8GetXFactEv + 200
44  librptuilo.dylib                    0x0000000337867600 _ZN5rptui9DlgEdFunc14isRectangleHitERK10MouseEvent + 948
Comment 23 Patrick Luby 2023-04-16 18:33:14 UTC
Created attachment 186705 [details]
Output from running in the Terminal
Comment 24 Patrick Luby 2023-04-16 20:12:07 UTC
(In reply to Patrick Luby from comment #23)
> Created attachment 186705 [details]
> Output from running in the Terminal

Ignore this attachment. This attachment is missing most of the data that I intended to upload.

I'll see if I can upload the full original log. For some reason, I am unable to upload attachments from either Safari or Firefox. Hopefully it is just some transitory stuff in Bugzilla.
Comment 25 Patrick Luby 2023-04-16 20:15:50 UTC
Created attachment 186706 [details]
Sample during crash when Recover Document dialog appears
Comment 26 Patrick Luby 2023-04-16 20:33:11 UTC
(In reply to Patrick Luby from comment #25)
> Created attachment 186706 [details]
> Sample during crash when Recover Document dialog appears

This is another crash but in a slightly different place in the code. What both have in common is that both crashes are occurring in the rptui::DlgEdFunc* functions. From the looks of both crashes, it looks like the rptui::DlgEdFunc* are invoking calls on deleted objects.

That is about as far as I can go. Unfortunately, I don't have any familiarity with the class types and lifecycle in the Base reporting code.
Comment 27 Patrick Luby 2023-08-01 00:14:10 UTC
I think that I have a fix for this bug. It isn't pretty, but it does stop the crashing:

https://gerrit.libreoffice.org/c/core/+/155119

Disclaimer: I know nothing about the flow of the report design code. I just traced pointer values in the bottommost functions causing the crash until I found where the pointer that causes the crash got deleted.
Comment 28 Commit Notification 2023-08-01 12:28:27 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/01a1d2a84992973b8a0e5f1ae99fd32f5913b58f

tdf#144072 prevent use of a deleted pointer

It will be available in 24.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 29 Patrick Luby 2023-08-01 14:16:25 UTC
(In reply to Commit Notification from comment #28)
> Patrick Luby committed a patch related to this issue.
> It has been pushed to "master":
> 

Please ignore this. I found my fix only delays the inevitable crash so I reverted my commit.

Ultimately, the problem is that the reportdesign code keeps reusing SdrHdl pointers like they live forever while the SdHdlList treats them as disposable objects.

Unfortunately, I have no idea how to rewrite this particular code to not reuse SdrHdl pointers.
Comment 30 Commit Notification 2023-08-01 19:24:29 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/73adf93acc9bbac4c8db9aa844930629a429410e

Revert "tdf#144072 prevent use of a deleted pointer"

It will be available in 24.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 31 Patrick Luby 2023-08-02 13:17:22 UTC
I came up with another fix and I have uploaded the following patch:

https://gerrit.libreoffice.org/c/core/+/155204

I rushed my last fix so I want to wait a while for my patch to be reviewed before I commit it. If anyone is able to test the patch in a local build, that would be very much appreciated.
Comment 32 Patrick Luby 2023-08-02 16:17:41 UTC
(In reply to Patrick Luby from comment #31)
> I came up with another fix and I have uploaded the following patch:
> 
> https://gerrit.libreoffice.org/c/core/+/155204
> 
> I rushed my last fix so I want to wait a while for my patch to be reviewed
> before I commit it. If anyone is able to test the patch in a local build,
> that would be very much appreciated.

Well I can't get my patch to pass the CI builds and a reviewer confirmed that my code doesn't fix the bug in a way they like so I have abandoned this patch.

I'm just an old volunteer debugger so maybe someone else can fix the broken reportdesign code in a way that is satisfactory to LibreOffice CI rules and reviewers.

That said, this pattern of code, while ugly, does work and isn't hard to understand but clearly the style is verboten. Oh well.
Comment 33 Noel Grandin 2023-08-03 10:14:35 UTC
Fix for this here:

https://gerrit.libreoffice.org/c/core/+/155284

I debugging this using an ASAN build, which helpfully gives me a nice stacktrace of who freed the offending object.

By comparing the stack of the crash to the stack of the free operation, I was able to see when the problem occurred.
Comment 34 Patrick Luby 2023-08-03 13:37:52 UTC
(In reply to Noel Grandin from comment #33)
> Fix for this here:
> 
> https://gerrit.libreoffice.org/c/core/+/155284
> 
> I debugging this using an ASAN build, which helpfully gives me a nice
> stacktrace of who freed the offending object.
> 
> By comparing the stack of the crash to the stack of the free operation, I
> was able to see when the problem occurred.

I tested the above patch and it works for me.

I think this is a very elegant fix. The key is that it refetches the SdrHdl after where they are deleted so the passed in SdrHdl parameter can be ignored.

That was the piece that was missing from my patches and it eliminates the need for my ugly "check if SdrHdl is still alive" code.

Thanks Noel!
Comment 35 Commit Notification 2023-08-03 16:06:04 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

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

tdf#144072 Base crash when 2 fields selected in reportbuilder..

It will be available in 24.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 36 Commit Notification 2023-08-04 08:36:54 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/228061cdf5571814c773eaab9b46a4f9a80071f4

tdf#144072 Base crash when 2 fields selected in reportbuilder..

It will be available in 7.6.1.

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 37 Patrick Luby 2023-08-04 12:10:17 UTC
Verified as fixed in the 04 August 2023 nightly master build:

Version: 24.2.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: 2b0b4ddc8bd8fdd4cd689300620fe4621d7533b7
CPU threads: 8; OS: Mac OS X 12.6.8; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded