Description: Running a macro, which worked in all previous version, makes crash LibreOffice if running under 24.8.3.2 Steps to Reproduce: I use for a long time a macro in sCalc which should resize and place picture I copy from the web (Copy image - CTRL+V). Until 24.8.2.5 it worked fine. After upgrade to 24.8.3.2 LO crashes if I run the macro. The crash report is here: https://crashreport.libreoffice.org/stats/crash_details/17f19588-b76d-4c20-9453-4f47db059cf8 The macro is: sub ResizeQR rem ---------------------------------------------------------------------- rem define variables dim document as object dim dispatcher as object rem ---------------------------------------------------------------------- rem get access to the document document = ThisComponent.CurrentController.Frame dispatcher = createUnoService("com.sun.star.frame.DispatchHelper") rem ---------------------------------------------------------------------- rem dispatcher.executeDispatch(document, ".uno:TransformDialog", "", 0, Array()) rem ---------------------------------------------------------------------- dim args2(3) as new com.sun.star.beans.PropertyValue args2(0).Name = "TransformPosX" args2(0).Value = 500 args2(1).Name = "TransformPosY" args2(1).Value = 500 args2(2).Name = "TransformWidth" args2(2).Value = 4300 args2(3).Name = "TransformHeight" args2(3).Value = 4940 dispatcher.executeDispatch(document, ".uno:TransformDialog", "", 0, args2()) end sub Actual Results: LO crashes Expected Results: Probably should not Reproducible: Always User Profile Reset: No Additional Info: As I am not very familiar with macros (this one I have founf probably somewhere on web) I am not sure, if there is something wrong in the macro (but i did not change it) or is this some bug of LO, as until 24.2.5.2 it worked.
I can confirm with Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: ec4415d2a78b1c0fb5eab5baea88508d6b9db43b CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: x11 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded It works in 7.3.7
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.8$. Adding Cc: to Armin Le Grand ; Could you possibly take a look at this one? Thanks 4651ba16352908e2c4d4791b833a471821e2996a is the first bad commit commit 4651ba16352908e2c4d4791b833a471821e2996a Author: Jenkins Build User <tdf@maggie.tdf> Date: Mon Feb 12 11:49:57 2024 +0100 source ca3c6d468f68af1506bf4e56b47655e5d56306a8 163157: ITEM: ItemPool Rework (I) | https://gerrit.libreoffice.org/c/core/+/163157
Is there a document that contains the macro that I can use for testing? I do not use macros and do not really know what to do to trigger/test this...
Created attachment 198187 [details] test file with macro It crash with vclplugin=gen, not GTK3. Steps: - open file - insert image - run macro
(In reply to Armin Le Grand (allotropia) from comment #3) > Is there a document that contains the macro that I can use for testing? I do > not use macros and do not really know what to do to trigger/test this... Hi Armin, 1. Open Calc 2. Insert an image 3. Tools - Macros - Edit Macros 4. Paste the macro in comment 1 5. Run (F5) -> Crash
Thanks to you both - that helps :-) Could reproduce on master. Then I checked-out 207501b8385818a5d413b9f4001e0d24aaa4f2a9 which is the version just before ca3c6d468f68af1506bf4e56b47655e5d56306a8 which is the mentioned change in comment2. It creates exactly the same crash in SfxItemPool::GetUserOrPoolDefaultItem which is no surprise: The macro creates an ItemSet with SlotIDs (crashing one is 10092 aka SID_ATTR_TRANSFORM_SIZE_POINT). SlotIDs (WhichIDs > 5000) have no defaults in the pool. That is why when creating ItemSets for UI usinng SlotIDs all entries have to be set. There are access methods to ItemSet which return a const& to an Item, these *rely* on an Item being set or - if not - a default to exist, else it asserts (see svl/source/items/itempool.cxx:725). I am wondering if that macro ever worked. Looking deeper...
Ah! Interesting: see svx/source/svdraw/svdedtv1.cxx:1667 if (bChgSiz) { if (bTiledRendering && SfxItemState::SET != rAttr.GetItemState(SID_ATTR_TRANSFORM_SIZE_POINT)) eSizePoint = RectPoint::LT; else eSizePoint = static_cast<RectPoint>(rAttr.Get(SID_ATTR_TRANSFORM_SIZE_POINT).GetValue()); } So before accessing the Item it *gets* checked if it is set - but *not* when bTiledRendering ios false - which is the case here. Thus the Item gets accessed *without* being set -> crash. This is clearly wrong I would say...
Fix on gerrit, see https://gerrit.libreoffice.org/c/core/+/178936
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5de080cae9bf09a2e360974e7b31567272c89798 tdf#164285 secure access to SID_ATTR_TRANSFORM_SIZE_POINT It will be available in 25.8.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.