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
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.
@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)
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.
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.
Created attachment 174550 [details] Apple Stack Trace produced on crash
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
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
(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
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.
I was Too Hasty - Still getting this behaviour in 7.2.0.4
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
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?
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
*** Bug 145362 has been marked as a duplicate of this bug. ***
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
(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
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.
(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?
(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.
(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.
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.
(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
Created attachment 186705 [details] Output from running in the Terminal
(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.
Created attachment 186706 [details] Sample during crash when Recover Document dialog appears
(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.
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.
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.
(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.
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.
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.
(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.
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.
(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!
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.
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.
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