Bug 156091 - BASIC IDE or Development Tools crash when expanding the + of 'Background' of master page
Summary: BASIC IDE or Development Tools crash when expanding the + of 'Background' of ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
24.2.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:24.2.0 target:7.6.0.0.beta2
Keywords:
Depends on:
Blocks: BASIC-IDE UNO-Object-Inspector
  Show dependency treegraph
 
Reported: 2023-06-28 20:15 UTC by Regina Henschel
Modified: 2023-09-08 12:56 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Presentation with gradient background on master slide (28.21 KB, application/vnd.oasis.opendocument.presentation)
2023-06-28 20:15 UTC, Regina Henschel
Details
Screenshot (329.82 KB, image/png)
2023-06-28 20:46 UTC, m_a_riosv
Details
bt with debug symbols (9.42 KB, text/plain)
2023-06-29 13:55 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2023-06-28 20:15:44 UTC
Created attachment 188122 [details]
Presentation with gradient background on master slide

This happens only in a development build.

Open attached file.
Open the Development Tools.
In the left part select Master Slides and then Standard.
In the right part use tab Properties.
Open the + of Background property => Crash.

The same crash happens when using the BASIC IDE with below macro.
Set a break point in line "dummy = 1".
Run the macro on the opened file.
Watch oMasterPage in the IDE.
Open the + of property Background in the Watch window. => Crash.

The property Background exists and you can open aPropertiesSeq in the Watch window.

sub examine_document
dim oDocument as variant: oDocument = ThisComponent
dim oMasterPage as object: oMasterPage = oDocument.MasterPages(0)
dim oBackground as object: oBackground = oMasterPage.Background
dim aPropertiesSeq as object: aPropertiesSeq = oBackground.getPropertySetInfo()
dim dummy as integer
dummy = 1: 'for setting break point
end sub
Comment 1 m_a_riosv 2023-06-28 20:46:52 UTC
Created attachment 188124 [details]
Screenshot

I can't reproduce
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: f1b0aca6bf520626d3c9a1fac67cd2de2c10c78c
CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Comment 2 Stéphane Guillou (stragu) 2023-06-28 22:58:35 UTC
I couldn't crash it either, with both the Development Tools and the macro methods.

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 3551d18404cb19cdaa8edb170a549f5c5405d0cb
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Which version info do you have, Regina?
Comment 3 Regina Henschel 2023-06-28 23:48:54 UTC
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 2e118b524fd390409595fbdaec7a96f10be2b534
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win
Locale: de-DE (en_US); UI: en-US
Calc: CL threaded

Do you have used a development build? The crash does not happen with a productive build.
Comment 4 QA Administrators 2023-06-29 03:13:23 UTC Comment hidden (obsolete)
Comment 5 Julien Nabet 2023-06-29 13:55:58 UTC
Created attachment 188129 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I got an assertion.
Comment 6 Julien Nabet 2023-06-29 14:26:12 UTC
Noticing property name "TextColumns", I noticed it's been added with: 95ebd24a629b4c8cd62cc20c0701683512cc8fa0
"editengine-columns: ODF support [API CHANGE]

This uses existing ODF markup, as used by Writer's text frame:
style::columns child element of style:graphic-properties, its
fo:column-count and fo:column-gap attributes. No ODF extension
is required.

Since currently only columns with same width and spacing are
implemented, without additional settings, style:column child
elements are exported, but ignored on import.

This adds new property to css::drawing::TextProperties service:
TextColumns (of type css::text::XTextColumns)."
in 2021/05

Mike: I noticed this part:
{ u"TextColumns", OWN_ATTR_TEXTCOLUMNS, cppu::UnoType<css::text::XTextColumns>::get(), 0, 0 }

shouldn't we create SDRATTR_TEXTCOLUMNS and then use it in include/svx/svddef.hxx
to replace:
    237 constexpr TypedWhichId<SdrOnOffItem>               SDRATTR_TEXT_CLIPVERTOVERFLOW   (SDRATTR_MISC_FIRST +26);     // 1095
    238 constexpr sal_uInt16                               SDRATTR_MISC_LAST               (SDRATTR_TEXT_CLIPVERTOVERFLOW); // 1095

by:
    237 constexpr TypedWhichId<SdrOnOffItem>               SDRATTR_TEXT_CLIPVERTOVERFLOW   (SDRATTR_MISC_FIRST +26);     // 1095
    238 constexpr TypedWhichId<SdrOnOffItem>               SSDRATTR_TEXTCOLUMNS   (SDRATTR_MISC_FIRST +27);     // 1096
    239 constexpr sal_uInt16                               SDRATTR_MISC_LAST               (SDRATTR_TEXTCOLUMNS); // 1096

I thought about a patch starting to write a patch from this, what do you think?
Comment 7 Mike Kaganski 2023-06-29 15:29:36 UTC
(In reply to Julien Nabet from comment #6)
> shouldn't we create SDRATTR_TEXTCOLUMNS and then use it in
> include/svx/svddef.hxx
> ...
>     238 constexpr TypedWhichId<SdrOnOffItem>              
> SSDRATTR_TEXTCOLUMNS   (SDRATTR_MISC_FIRST +27);     // 1096

I suppose text columns wouldn't be an On Off Item. I don't remember it clearly, but my first instinct would be to try to mimic what SvxXTextColumns::getPropertyValue does with this WID, and proceed with implementation of columns support in the Draw styles.

I suggest you to start, and we could proceed with discussing a gerrit change. Thank you!
Comment 8 Julien Nabet 2023-06-29 18:42:20 UTC
(In reply to Mike Kaganski from comment #7)
> ...
> I suggest you to start, and we could proceed with discussing a gerrit
> change. Thank you!

Started here https://gerrit.libreoffice.org/c/core/+/153772
Comment 9 Julien Nabet 2023-06-29 19:55:23 UTC
(In reply to Julien Nabet from comment #8)
> ...
> Started here https://gerrit.libreoffice.org/c/core/+/153772

Just for the record, I abandoned the patch since it's too much complicated for me. Hopefully, someone will be able to fix this properly :-)
Comment 10 Mike Kaganski 2023-06-29 20:04:16 UTC
(In reply to Julien Nabet from comment #9)

Thank you! You made a great detective work, and provided ideas. I will take over.
Comment 11 Mike Kaganski 2023-06-29 21:05:32 UTC
https://gerrit.libreoffice.org/c/core/+/153777
Comment 12 Commit Notification 2023-06-29 23:04:31 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4e20f95cf6744ca85bc8c090b926031729addc89

tdf#156091: handle OWN_ATTR_TEXTCOLUMNS in SdStyleSheet::getPropertyValue_Impl

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 13 Commit Notification 2023-07-03 09:37:49 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/7bac5ef6388f5417febc172b3b79fe986752a837

tdf#156091: handle OWN_ATTR_TEXTCOLUMNS in SdStyleSheet::getPropertyValue_Impl

It will be available in 7.6.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.