Bug 106792 - Error when saving a polygon with points converted to curve
Summary: Error when saving a polygon with points converted to curve
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha1
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Armin Le Grand
URL:
Whiteboard: target:6.2.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2017-03-27 10:31 UTC by MSchwarzenberg
Modified: 2021-03-29 21:17 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MSchwarzenberg 2017-03-27 10:31:13 UTC
How to reproduce:

- Start libre office
- create new draw document
- draw a polygon with some points
- Edit -> Points (F8)
- select one or more points 
- convert the point(s) to curve using the "Convert to Curve" icon in the toolbar (not the edit menu, not the right mouse button popup)
- Save the file
- After entering the filename, Draw crashes.
Comment 1 Xisco Faulí 2017-03-27 10:56:20 UTC
I can't reproduce the crash in

Version: 5.3.1.2
Build ID: 1:5.3.1-0ubuntu1~yakkety0
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Layout Engine: new; 
Locale: es-ES (ca_ES.UTF-8); Calc: group

nor 

Version: 5.4.0.0.alpha0+
Build ID: 193f8966135064a32164c9da08d01dab9c1fc15d
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

However, I get this error when I try to save the file:

saving the document Untitled 2:
Write Error.
The file could not be written.

which is not displayed in 

Version: 5.2.0.0.alpha1+
Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; 
Locale: ca-ES (ca_ES.UTF-8)

Changing the summary accordingly 

Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
Comment 2 Xisco Faulí 2017-03-27 11:13:45 UTC
Regression introduced by:

author	Stephan Bergmann <sbergman@redhat.com>	2016-06-02 13:06:06 (GMT)
committer	Stephan Bergmann <sbergman@redhat.com>	2016-06-02 13:33:59 (GMT)
commit 0d7c5823124696f80583ac2a5f0e28f329f6f786 (patch)
tree c62e4a5490e941f39d775477f1529e9c869fa273
parent e5d8dc12fcf64fbbefadefbe863c772dc9134d38 (diff)
New o3tl::try/doGet to obtain value from Any

Bisected with bibisect-linux-64-5.3

Adding Cc: to Stephan Bergmann
Comment 3 MSchwarzenberg 2017-03-28 15:38:34 UTC
No crash using Version: 5.3.1.2
Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2
CPU Threads: 6; OS Version: Linux 4.9; UI Render: default; VCL: gtk2; Layout Engine: new; 
Locale: de-DE (de_DE.iso885915@euro); Calc: group
Comment 4 Commit Notification 2017-03-29 08:13:17 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=26909d9de4c6e7165fc8f5d938ee6ef55b87cc5c

tdf#106792: Fix "Geometry" property of changed-to-bezier SvxShapePolyPolygon

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 5 MSchwarzenberg 2017-03-30 10:38:36 UTC
Thanks for the quick fix. Is there a chance to get it into the "still" version (5.2.6.x) ?
Comment 6 Julien Nabet 2017-03-31 23:42:48 UTC
I don't know if it worths it for 5.2 branch but I cherry-picked the patch on 5.3 branch for review, see https://gerrit.libreoffice.org/#/c/35988/
(Stephan: hope you're ok with this, if not, don't hesitate to tell me and I abandon the patch).
Comment 7 Stephan Bergmann 2017-04-03 09:29:14 UTC
(In reply to Julien Nabet from comment #6)
> I don't know if it worths it for 5.2 branch but I cherry-picked the patch on
> 5.3 branch for review, see https://gerrit.libreoffice.org/#/c/35988/
> (Stephan: hope you're ok with this, if not, don't hesitate to tell me and I
> abandon the patch).

I'd hoped for an answer to <https://lists.freedesktop.org/archives/libreoffice/2017-March/077443.html> "[Libreoffice-commits] core.git: tdf#106792: Fix 'Geometry' property of changed-to-bezier SvxShapePolyPolygon" first.  But lets keep the backport request open now that you've created it already.
Comment 8 Stephan Bergmann 2017-04-05 06:01:30 UTC
(In reply to Xisco Faulí from comment #2)
> Regression introduced by:
> 
> author	Stephan Bergmann <sbergman@redhat.com>	2016-06-02 13:06:06 (GMT)
> committer	Stephan Bergmann <sbergman@redhat.com>	2016-06-02 13:33:59 (GMT)
> commit 0d7c5823124696f80583ac2a5f0e28f329f6f786 (patch)
> tree c62e4a5490e941f39d775477f1529e9c869fa273
> parent e5d8dc12fcf64fbbefadefbe863c772dc9134d38 (diff)
> New o3tl::try/doGet to obtain value from Any
> 
> Bisected with bibisect-linux-64-5.3

It is more of a coincidence that the behavior changed from an (unreliable) crash (or potential silent data corruption, etc.) to a reliable "Write Error" message with the above commit.

Bibisecting further with <git://dev-downloads.libreoffice.org/lo-linux-dbgutil-daily-till51.git> indicates that the underlying error (of an SvxShapePolyPolygon not changing to SvxShapePolyPolygonBezier upon "Convert to Curve") got introduced with

> commit 97e4cfbb943a38683c30c02fde5d44fe5f4bb1a4
> Author: Miklos Vajna <vmiklos@collabora.co.uk>
> Date:   Fri Jun 26 05:51:07 2015 +0200
> 
>     2015-06-26: source-hash-ee3d40b30816a8fc6d4e8f984659c8dfac19ec3b

i.e., one of the 99 source commits in the range e8938f2ddb5efa8a34d05995cd55cf337c7aaeff..ee3d40b30816a8fc6d4e8f984659c8dfac19ec3b.
Comment 9 Stephan Bergmann 2017-04-05 12:52:24 UTC
(In reply to Stephan Bergmann from comment #8)
> > commit 97e4cfbb943a38683c30c02fde5d44fe5f4bb1a4
> > Author: Miklos Vajna <vmiklos@collabora.co.uk>
> > Date:   Fri Jun 26 05:51:07 2015 +0200
> > 
> >     2015-06-26: source-hash-ee3d40b30816a8fc6d4e8f984659c8dfac19ec3b
> 
> i.e., one of the 99 source commits in the range
> e8938f2ddb5efa8a34d05995cd55cf337c7aaeff..
> ee3d40b30816a8fc6d4e8f984659c8dfac19ec3b.

Made a mistake there, the first bad commit is rather

> commit 2e88714919324d1794d4ba66b1f27e9d2746e773
> Author: Miklos Vajna <vmiklos@collabora.co.uk>
> Date:   Sat Jun 27 05:50:50 2015 +0200
> 
>     2015-06-27: source-hash-efa2c05e84d0696b31bd822d3234798be43853ad

i.e., one of the 78 source commits in the range ee3d40b30816a8fc6d4e8f984659c8dfac19ec3b..efa2c05e84d0696b31bd822d3234798be43853ad.
Comment 10 Stephan Bergmann 2017-04-06 09:09:46 UTC
Bisecting further, under vclplug_gtk3 on Linux this happens to appear first with <https://cgit.freedesktop.org/libreoffice/core/commit/?id=093d7b8142d0cb224fcf23506f3b36f7a3a10d2c> "Resolves: tdf#92293 gtk3: get a11y working".  Turns out there's an SdrPathObj and associated SvxShape (which is held weakly, so typically disappears quickly and gets recreated when needed), and the SdrPathObj changes its kind when the user turns one of its edges into a Bezier curve.  That should cause the associated SvxShape to be recreated as an SvxShapePolyPolygonBezier instead of a SvxShapePolyPolygon the next time it is needed.  But with the a11y bridge enabled, the original SvxShapePolyPolygon is apparently held strongly from somewhere, so the change of the SdrPathObj's kind isn't reflected in the type of the associated SvxShape as intended.

So the commit from comment 4 was wrongly addressing symptoms, not the root cause, and will be reverted again.  Work on a proper fix is ongoing.
Comment 11 Commit Notification 2017-04-06 09:20:52 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9458ce11084579b020650fecb1165052c16ee556

Revert "tdf#106792: Fix "Geometry" property of changed-to-bezier SvxShapePolyPolygon"

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Stephan Bergmann 2017-06-08 12:04:35 UTC
> Jun 07 11:18:35 <sberg> alg, do you happen to have a good idea how to fix <https://bugs.documentfoundation.org/show_bug.cgi?id=106792#c10>?  SvxShape vs. SdrPathObj, made me give up in despair :(
> Jun 08 13:45:30 <alg>   sberg: no good idea - question is if we should allow type change at all. Otoh having more than a single SvxShapePolyPolygon is historicvally and no good decision from my pov
> Jun 08 13:46:40 <alg>   sberg: the one would mean to consequently exchange the SdrObject (with undo, in the contained list, etc...). The other to get rid of all other SvxShapePolygon types
> Jun 08 13:48:14 <alg>   sberg: in aw080 I already had removed the object types (OBJ_*), extended the UNO APIs for polygons to understand all sorts of polygons and the exporter to automatically choose the one with the highest complexity. But that's a big change...
Comment 13 QA Administrators 2018-06-09 02:40:40 UTC Comment hidden (obsolete)
Comment 14 Stephan Bergmann 2018-06-11 16:22:06 UTC
I can still reproduce with a local recent master build (towards LO 6.2) the "write error" failure from comment 1 when following the recipe from comment 0.
Comment 15 Bruno Vellutini 2018-06-14 14:57:35 UTC
I'm also experiencing the "Write Error" after using "Convert to Curve" on Impress:

Version: 6.0.4.2
Build ID: 1:6.0.4~rc2-0ubuntu0.18.04.1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 16 Armin Le Grand 2018-06-28 17:22:30 UTC
@sberg: Lost a little bit out-of-focus, thinking about it. Having just SvxShapePolyPolygon and no impl for SvxShapePolyPolygonBezier and adapting stuff is probably best - trying out...
Comment 17 Armin Le Grand 2018-06-28 17:45:30 UTC
Cannot really recreate with current version - sberg, can you retry with current master, please?
Comment 18 Stephan Bergmann 2018-06-29 08:42:27 UTC
(In reply to Armin Le Grand (CIB) from comment #17)
> Cannot really recreate with current version - sberg, can you retry with
> current master, please?

Can still reproduce with a recent local (Linux x86-64, --enable-dbgutil) master build:  Follow the instructions from comment 0 to get the "Write Error" box from comment 1.  (See comment 8 on why the behavior changed from a crash to an error box.)
Comment 19 Armin Le Grand 2018-07-02 16:07:10 UTC
This opened a little bit the box of the pandora due to quite some conversions were missing in tne UNO API implementation between 100thmm and twips due to UNO API being by definition on 100thmm. Of course I corrected these and got massive errors in UnitTests getting values from the UNO API comaring these to 'numbers' - no try to think about units used...
Comment 20 Armin Le Grand 2018-07-02 16:07:55 UTC
Fix (and adaptions and other changes, see https://gerrit.libreoffice.org/#/c/56614/) in master
Comment 21 Julien Nabet 2018-07-02 17:11:00 UTC
Armin: just for information, in order to make the link automatically between gerrit and bugzilla, you need to add a "#"
So instead of "tdf106792", it should be "tdf#106792".
Just nitpick of course, thank you for the fix! :-)
Comment 22 Armin Le Grand 2018-07-02 17:33:23 UTC
Hi Julien, thanks for the hint - seems as if I just mis-typed there, argh. In fact I was already waiting for the comment to show up here ;-)
Comment 23 Adolfo Jayme Barrientos 2018-07-02 19:45:14 UTC
OK, for the sake of completeness, Armin’s commit is: https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=36bade04d3780bc54c51b46bb0b63e69789658a5
Comment 24 Armin Le Grand 2018-07-03 10:06:49 UTC
@sberg: If you by coincidence have a relatively current master, could you check if you can still reproduce, please..?
Comment 25 Stephan Bergmann 2018-07-03 12:44:16 UTC
My local ASan+UBSan build now fails in CppunitTest_sw_ooxmlexport9 in a way that smells related to the fix for this issue?

> ==19914==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f8cfb8b582c at pc 0x7f8cddf991c8 bp 0x7fff5a687c10 sp 0x7fff5a687c08
> READ of size 4 at 0x7f8cfb8b582c thread T0
>  #0 in basegfx::utils::UnoPolygonBezierCoordsToB2DPolygon(com::sun::star::uno::Sequence<com::sun::star::awt::Point> const&, com::sun::star::uno::Sequence<com::sun::star::drawing::PolygonFlags> const&) at basegfx/source/polygon/b2dpolygontools.cxx:3292:76 (instdir/program/libbasegfxlo.so +0x5991c7)
>  #1 in basegfx::utils::UnoPolyPolygonBezierCoordsToB2DPolyPolygon(com::sun::star::drawing::PolyPolygonBezierCoords const&) at basegfx/source/polygon/b2dpolypolygontools.cxx:651:50 (instdir/program/libbasegfxlo.so +0x68e145)
>  #2 in SvxShapePolyPolygon::setPropertyValueImpl(rtl::OUString const&, SfxItemPropertySimpleEntry const*, com::sun::star::uno::Any const&) at svx/source/unodraw/unoshap2.cxx:944:17 (instdir/program/libsvxcorelo.so +0x52c08ad)
>  #3 in SvxShape::_setPropertyValue(rtl::OUString const&, com::sun::star::uno::Any const&) at svx/source/unodraw/unoshape.cxx:1668:9 (instdir/program/libsvxcorelo.so +0x5362f3a)
>  #4 in SvxShape::setPropertyValue(rtl::OUString const&, com::sun::star::uno::Any const&) at svx/source/unodraw/unoshape.cxx:1626:9 (instdir/program/libsvxcorelo.so +0x536140a)
>  #5 in SwXShape::setPropertyValue(rtl::OUString const&, com::sun::star::uno::Any const&) at sw/source/core/unocore/unodraw.cxx:1442:28 (instdir/program/libswlo.so +0xb20cd8c)
>  #6 in oox::PropertySet::implSetPropertyValue(rtl::OUString const&, com::sun::star::uno::Any const&) at oox/source/helper/propertyset.cxx:131:20 (instdir/program/libooxlo.so +0x2bb70be)
>  #7 in oox::PropertySet::setAnyProperty(int, com::sun::star::uno::Any const&) at oox/source/helper/propertyset.cxx:71:12 (instdir/program/libooxlo.so +0x2bb6c2b)
>  #8 in bool oox::PropertySet::setProperty<com::sun::star::drawing::PolyPolygonBezierCoords>(int, com::sun::star::drawing::PolyPolygonBezierCoords const&) at include/oox/helper/propertyset.hxx:109:38 (instdir/program/libooxlo.so +0x31de0ae)
>  #9 in oox::vml::BezierShape::implConvertAndInsert(com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&, com::sun::star::awt::Rectangle const&) const at oox/source/vml/vmlshape.cxx:1107:18 (instdir/program/libooxlo.so +0x31c6bd5)
>  #10 in oox::vml::ShapeBase::convertAndInsert(com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&, oox::vml::ShapeParentAnchor const*) const at oox/source/vml/vmlshape.cxx:350:22 (instdir/program/libooxlo.so +0x31a4343)
>  #11 in oox::vml::ShapeContainer::convertAndInsert(com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&, oox::vml::ShapeParentAnchor const*) const at oox/source/vml/vmlshapecontainer.cxx:129:16 (instdir/program/libooxlo.so +0x3121801)
>  #12 in oox::vml::GroupShape::implConvertAndInsert(com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&, com::sun::star::awt::Rectangle const&) const at oox/source/vml/vmlshape.cxx:1402:21 (instdir/program/libooxlo.so +0x31d276f)
>  #13 in oox::vml::ShapeBase::convertAndInsert(com::sun::star::uno::Reference<com::sun::star::drawing::XShapes> const&, oox::vml::ShapeParentAnchor const*) const at oox/source/vml/vmlshape.cxx:350:22 (instdir/program/libooxlo.so +0x31a4343)
>  #14 in oox::shape::ShapeContextHandler::getShape() at oox/source/shape/ShapeContextHandler.cxx:422:35 (instdir/program/libooxlo.so +0x2fc971d)
>  #15 in non-virtual thunk to oox::shape::ShapeContextHandler::getShape() at oox/source/shape/ShapeContextHandler.cxx (instdir/program/libooxlo.so +0x2fd153f)
>  #16 in writerfilter::ooxml::OOXMLFastContextHandlerShape::sendShape(int) at writerfilter/source/ooxml/OOXMLFastContextHandler.cxx:1661:64 (instdir/program/libwriterfilterlo.so +0x1b4e638)
>  #17 in writerfilter::ooxml::OOXMLFastContextHandlerShape::lcl_endFastElement(int) at writerfilter/source/ooxml/OOXMLFastContextHandler.cxx:1687:9 (instdir/program/libwriterfilterlo.so +0x1b4f229)
>  #18 in writerfilter::ooxml::OOXMLFastContextHandler::endFastElement(int) at writerfilter/source/ooxml/OOXMLFastContextHandler.cxx:174:9 (instdir/program/libwriterfilterlo.so +0x1b21f25)
>  #19 in (anonymous namespace)::Entity::endElement() at sax/source/fastparser/fastparser.cxx:487:23 (instdir/program/libexpwraplo.so +0x2588a0)
>  #20 in sax_fastparser::FastSaxParserImpl::callbackEndElement() at sax/source/fastparser/fastparser.cxx:1263:17 (instdir/program/libexpwraplo.so +0x25819b)
>  #21 in (anonymous namespace)::call_callbackEndElement(void*, unsigned char const*, unsigned char const*, unsigned char const*) at sax/source/fastparser/fastparser.cxx:314:18 (instdir/program/libexpwraplo.so +0x24a17c)
>  #22 in xmlParseEndTag2 at workdir/UnpackedTarball/libxml2/parser.c:9680:2 (instdir/program/libxml2.so.2 +0x6e9871)
>  #23 in xmlParseTryOrFinish at workdir/UnpackedTarball/libxml2/parser.c:11531:7 (instdir/program/libxml2.so.2 +0x72228f)
>  #24 in xmlParseChunk__internal_alias at workdir/UnpackedTarball/libxml2/parser.c:12244:13 (instdir/program/libxml2.so.2 +0x70e3eb)
>  #25 in sax_fastparser::FastSaxParserImpl::parse() at sax/source/fastparser/fastparser.cxx:1032:21 (instdir/program/libexpwraplo.so +0x247916)
>  #26 in sax_fastparser::FastSaxParserImpl::parseStream(com::sun::star::xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:841:9 (instdir/program/libexpwraplo.so +0x241ffd)
>  #27 in sax_fastparser::FastSaxParser::parseStream(com::sun::star::xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:1334:13 (instdir/program/libexpwraplo.so +0x25b0fb)
>  #28 in writerfilter::ooxml::OOXMLDocumentImpl::resolve(writerfilter::Stream&) at writerfilter/source/ooxml/OOXMLDocumentImpl.cxx:503:22 (instdir/program/libwriterfilterlo.so +0x1ada935)
>  #29 in WriterFilter::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at writerfilter/source/filter/WriterFilter.cxx:185:24 (instdir/program/libwriterfilterlo.so +0x1a995d4)
>  #30 in SfxObjectShell::ImportFrom(SfxMedium&, com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&) at sfx2/source/doc/objstor.cxx:2228:34 (instdir/program/libsfxlo.so +0x3963a8f)
>  #31 in SfxObjectShell::DoLoad(SfxMedium*) at sfx2/source/doc/objstor.cxx:769:23 (instdir/program/libsfxlo.so +0x392d931)
>  #32 in SfxBaseModel::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at sfx2/source/doc/sfxbasemodel.cxx:1795:36 (instdir/program/libsfxlo.so +0x3ad572a)
>  #33 in (anonymous namespace)::SfxFrameLoader_Impl::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) at sfx2/source/view/frmload.cxx:687:28 (instdir/program/libsfxlo.so +0x417857a)
>  #34 in framework::LoadEnv::impl_loadContent() at framework/source/loadenv/loadenv.cxx:1148:37 (instdir/program/libfwklo.so +0x150f2f7)
>  #35 in framework::LoadEnv::startLoading() at framework/source/loadenv/loadenv.cxx:382:20 (instdir/program/libfwklo.so +0x14ffb6b)
>  #36 in framework::LoadEnv::loadComponentFromURL(com::sun::star::uno::Reference<com::sun::star::frame::XComponentLoader> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at framework/source/loadenv/loadenv.cxx:168:14 (instdir/program/libfwklo.so +0x14fb8da)
>  #37 in framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at framework/source/services/desktop.cxx:618:12 (instdir/program/libfwklo.so +0x1667a30)
>  #38 in non-virtual thunk to framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at framework/source/services/desktop.cxx (instdir/program/libfwklo.so +0x1667c3a)
>  #39 in unotest::MacrosTest::loadFromDesktop(rtl::OUString const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at unotest/source/cpp/macros_test.cxx:50:60 (workdir/LinkTarget/CppunitTest/../Library/libunotest.so +0x8fb18)
>  #40 in SwModelTestBase::loadURL(rtl::OUString const&, char const*, char const*) at sw/qa/extras/inc/swmodeltestbase.hxx:732:23 (workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport9.so +0x359e63)
>  #41 in SwModelTestBase::load(rtl::OUString const&, char const*, char const*) at sw/qa/extras/inc/swmodeltestbase.hxx:687:16 (workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport9.so +0x3588e8)
>  #42 in SwModelTestBase::executeImportTest(char const*, char const*) at sw/qa/extras/inc/swmodeltestbase.hxx:264:13 (workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport9.so +0x357fd1)
>  #43 in testTdf104115::Import() at sw/qa/extras/ooxmlexport/ooxmlexport9.cxx:581:1 (workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport9.so +0x495e6d)
>  #44 in void std::__invoke_impl<void, void (testTdf104115::*&)(), testTdf104115*&>(std::__invoke_memfun_deref, void (testTdf104115::*&&&)(), testTdf104115*&&&) at /usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/bits/invoke.h:73:14 (workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport9.so +0x499acd)
>  #45 in std::__invoke_result<void (testTdf104115::*&)(), testTdf104115*&>::type std::__invoke<void (testTdf104115::*&)(), testTdf104115*&>(void (testTdf104115::*&&&)(), testTdf104115*&&&) at /usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/bits/invoke.h:95:14 (workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport9.so +0x4996db)
>  #46 in void std::_Bind<void (testTdf104115::* (testTdf104115*))()>::__call<void, 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) at /usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/functional:400:11 (workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport9.so +0x499546)
>  #47 in void std::_Bind<void (testTdf104115::* (testTdf104115*))()>::operator()<void>() at /usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/functional:482:17 (workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport9.so +0x4991de)
>  #48 in std::_Function_handler<void (), std::_Bind<void (testTdf104115::* (testTdf104115*))()> >::_M_invoke(std::_Any_data const&) at /usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/bits/std_function.h:297:2 (workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport9.so +0x498166)
>  #49 in std::function<void ()>::operator()() const at /usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/bits/std_function.h:687:14 (workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport9.so +0x379e43)
>  #50 in CppUnit::TestCaller<testTdf104115>::runTest() at workdir/UnpackedTarball/cppunit/include/cppunit/TestCaller.h:175:7 (workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport9.so +0x4970a6)
>  #51 in CppUnit::TestCaseMethodFunctor::operator()() const at workdir/UnpackedTarball/cppunit/src/cppunit/TestCase.cpp:32:5 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x2b3afe)
>  #52 in (anonymous namespace)::Protector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) at test/source/vclbootstrapprotector.cxx:48:14 (workdir/LinkTarget/Library/libvclbootstrapprotector.so +0x1bb8)
>  #53 in CppUnit::ProtectorChain::ProtectFunctor::operator()() const at workdir/UnpackedTarball/cppunit/src/cppunit/ProtectorChain.cpp:20:25 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x284986)
>  #54 in (anonymous namespace)::Prot::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) at unotest/source/cpp/unobootstrapprotector/unobootstrapprotector.cxx:89:12 (workdir/LinkTarget/Library/unobootstrapprotector.so +0xd138)
>  #55 in CppUnit::ProtectorChain::ProtectFunctor::operator()() const at workdir/UnpackedTarball/cppunit/src/cppunit/ProtectorChain.cpp:20:25 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x284986)
>  #56 in (anonymous namespace)::Prot::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) at unotest/source/cpp/unoexceptionprotector/unoexceptionprotector.cxx:63:16 (workdir/LinkTarget/Library/unoexceptionprotector.so +0x6758)
>  #57 in CppUnit::ProtectorChain::ProtectFunctor::operator()() const at workdir/UnpackedTarball/cppunit/src/cppunit/ProtectorChain.cpp:20:25 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x284986)
>  #58 in CppUnit::DefaultProtector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) at workdir/UnpackedTarball/cppunit/src/cppunit/DefaultProtector.cpp:15:12 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x21af58)
>  #59 in CppUnit::ProtectorChain::ProtectFunctor::operator()() const at workdir/UnpackedTarball/cppunit/src/cppunit/ProtectorChain.cpp:20:25 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x284986)
>  #60 in CppUnit::ProtectorChain::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) at workdir/UnpackedTarball/cppunit/src/cppunit/ProtectorChain.cpp:86:18 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x27e06c)
>  #61 in CppUnit::TestResult::protect(CppUnit::Functor const&, CppUnit::Test*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at workdir/UnpackedTarball/cppunit/src/cppunit/TestResult.cpp:182:28 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x315e61)
>  #62 in CppUnit::TestCase::run(CppUnit::TestResult*) at workdir/UnpackedTarball/cppunit/src/cppunit/TestCase.cpp:91:13 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x2b1e02)
>  #63 in CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) at workdir/UnpackedTarball/cppunit/src/cppunit/TestComposite.cpp:64:30 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x2b5ed9)
>  #64 in CppUnit::TestComposite::run(CppUnit::TestResult*) at workdir/UnpackedTarball/cppunit/src/cppunit/TestComposite.cpp:23:3 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x2b5148)
>  #65 in CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) at workdir/UnpackedTarball/cppunit/src/cppunit/TestComposite.cpp:64:30 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x2b5ed9)
>  #66 in CppUnit::TestComposite::run(CppUnit::TestResult*) at workdir/UnpackedTarball/cppunit/src/cppunit/TestComposite.cpp:23:3 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x2b5148)
>  #67 in CppUnit::TestRunner::WrappingSuite::run(CppUnit::TestResult*) at workdir/UnpackedTarball/cppunit/src/cppunit/TestRunner.cpp:47:27 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x343d58)
>  #68 in CppUnit::TestResult::runTest(CppUnit::Test*) at workdir/UnpackedTarball/cppunit/src/cppunit/TestResult.cpp:149:9 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x31493b)
>  #69 in CppUnit::TestRunner::run(CppUnit::TestResult&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) at workdir/UnpackedTarball/cppunit/src/cppunit/TestRunner.cpp:96:14 (workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.14.so.0 +0x344c67)
>  #70 in (anonymous namespace)::ProtectedFixtureFunctor::run() const at sal/cppunittester/cppunittester.cxx:315:20 (workdir/LinkTarget/Executable/cppunittester +0x540171)
>  #71 in sal_main() at sal/cppunittester/cppunittester.cxx:465:20 (workdir/LinkTarget/Executable/cppunittester +0x53cf51)
>  #72 in main at sal/cppunittester/cppunittester.cxx:372:1 (workdir/LinkTarget/Executable/cppunittester +0x53bf5e)
>  #73 in __libc_start_main at /usr/src/debug/glibc-2.27-63-g80c83e9114/csu/../csu/libc-start.c:308:16 (/lib64/libc.so.6 +0x2318a)
>  #74 in _start at <null> (workdir/LinkTarget/Executable/cppunittester +0x42f349)
> 
> 0x7f8cfb8b582c is located 0 bytes to the right of global variable 'cppu::g_emptySeq' defined in 'cppu/source/uno/data.cxx:40:14' (0x7f8cfb8b5820) of size 12
> SUMMARY: AddressSanitizer: global-buffer-overflow basegfx/source/polygon/b2dpolygontools.cxx:3292:76 in basegfx::utils::UnoPolygonBezierCoordsToB2DPolygon(com::sun::star::uno::Sequence<com::sun::star::awt::Point> const&, com::sun::star::uno::Sequence<com::sun::star::drawing::PolygonFlags> const&)
> Shadow bytes around the buggy address:
>   0x0ff21f70eab0: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
>   0x0ff21f70eac0: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
>   0x0ff21f70ead0: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
>   0x0ff21f70eae0: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
>   0x0ff21f70eaf0: f9 f9 f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 f9 f9
> =>0x0ff21f70eb00: f9 f9 00 00 00[04]f9 f9 f9 f9 f9 f9 00 00 00 00
>   0x0ff21f70eb10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0ff21f70eb20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0ff21f70eb30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0ff21f70eb40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0ff21f70eb50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:           00
>   Partially addressable: 01 02 03 04 05 06 07 
>   Heap left redzone:       fa
>   Freed heap region:       fd
>   Stack left redzone:      f1
>   Stack mid redzone:       f2
>   Stack right redzone:     f3
>   Stack after return:      f5
>   Stack use after scope:   f8
>   Global redzone:          f9
>   Global init order:       f6
>   Poisoned by user:        f7
>   Container overflow:      fc
>   Array cookie:            ac
>   Intra object redzone:    bb
>   ASan internal:           fe
>   Left alloca redzone:     ca
>   Right alloca redzone:    cb
>   Shadow gap:              cc
> ==19914==ABORTING
Comment 26 Stephan Bergmann 2018-07-03 12:48:33 UTC
...but the original issue appears to be indeed fixed.
Comment 27 Stephan Bergmann 2018-07-04 07:45:38 UTC
(In reply to Stephan Bergmann from comment #25)
> My local ASan+UBSan build now fails in CppunitTest_sw_ooxmlexport9 in a way
> that smells related to the fix for this issue?

see also <https://gerrit.libreoffice.org/#/c/56921/> "nCount must apparently be non-zero here"
Comment 28 Xisco Faulí 2018-07-05 11:13:51 UTC
Issue verified in

Version: 6.2.0.0.alpha0+
Build ID: 0e83efbccc180c957f77291fc0fdc6dd74eae0f4
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded

@Armin, thanks for fixing this!!