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.
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/ ?
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
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
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.
Thanks for the quick fix. Is there a chance to get it into the "still" version (5.2.6.x) ?
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).
(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.
(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.
(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.
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.
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.
> 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...
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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.
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
@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...
Cannot really recreate with current version - sberg, can you retry with current master, please?
(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.)
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...
Fix (and adaptions and other changes, see https://gerrit.libreoffice.org/#/c/56614/) in master
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! :-)
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 ;-)
OK, for the sake of completeness, Armin’s commit is: https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=36bade04d3780bc54c51b46bb0b63e69789658a5
@sberg: If you by coincidence have a relatively current master, could you check if you can still reproduce, please..?
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
...but the original issue appears to be indeed fixed.
(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"
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!!