Re: Trying to solve a crasher in editeng unit test
On Fri, 2012-04-13 at 12:14 -0400, Kohei Yoshida wrote: > On Fri, Apr 13, 2012 at 8:15 AM, Caolán McNamara wrote: > > reenabled editeng test again, and await inevitable fallout on some > > platform or other. > > Keeping my fingers crossed. :-) Inevitable platform fallout on windows happened, now fixed I think. At least the windows tinderboxs stopped bleating at me. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Trying to solve a crasher in editeng unit test
On Fri, Apr 13, 2012 at 8:15 AM, Caolán McNamara wrote: >> Yes. Some of my changes were an attempt to address that > > ok, plan b, reorganize matters so that we bootstrap the initial uno > component context once before all tests, and dispose it once after all > tests are complete. Rather than setup/teardown before/after each test > which just doesn't fly so well. Thanks Caolan, for solving this. I just didn't realize how tangled up the life cycle of these singleton objects was... > reenabled editeng test again, and await inevitable fallout on some > platform or other. Keeping my fingers crossed. :-) Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Trying to solve a crasher in editeng unit test
On Thu, 2012-04-12 at 10:14 -0400, Kohei Yoshida wrote: > On Thu, Apr 12, 2012 at 10:06 AM, Caolán McNamara wrote: > > *mumable* unotest::testDown has its "dispose" commented out ages ago, > > putting that back in shows some other problems with various mixes of > > global singletons that exist for the duration of a test-suite and the > > per-test globals which get setup and reset for each test. > > Yes. Some of my changes were an attempt to address that ok, plan b, reorganize matters so that we bootstrap the initial uno component context once before all tests, and dispose it once after all tests are complete. Rather than setup/teardown before/after each test which just doesn't fly so well. reenabled editeng test again, and await inevitable fallout on some platform or other. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Trying to solve a crasher in editeng unit test
On Thu, Apr 12, 2012 at 10:06 AM, Caolán McNamara wrote: > On Thu, 2012-04-12 at 09:46 -0400, Kohei Yoshida wrote: >> Crap. Maybe a unit test in editeng wasn't such a good idea after all. > > I disabled it and backed out a few bit for the moment. I have a fairly > good idea what the various problems are so I might have a go at fixing > it up again in a bit. > > *mumable* unotest::testDown has its "dispose" commented out ages ago, > putting that back in shows some other problems with various mixes of > global singletons that exist for the duration of a test-suite and the > per-test globals which get setup and reset for each test. Yes. Some of my changes were an attempt to address that. But apparently my skill is not up for it. I give up now. You did the right thing by backing out my changes. Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Trying to solve a crasher in editeng unit test
On Thu, 2012-04-12 at 09:46 -0400, Kohei Yoshida wrote: > Crap. Maybe a unit test in editeng wasn't such a good idea after all. I disabled it and backed out a few bit for the moment. I have a fairly good idea what the various problems are so I might have a go at fixing it up again in a bit. *mumable* unotest::testDown has its "dispose" commented out ages ago, putting that back in shows some other problems with various mixes of global singletons that exist for the duration of a test-suite and the per-test globals which get setup and reset for each test. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Trying to solve a crasher in editeng unit test
On 12/04/12 15:46, Kohei Yoshida wrote: > Crap. Maybe a unit test in editeng wasn't such a good idea after all. while i haven't looked at what your test does, i noticed that a lot of these so-called "unit tests" need pretty much a whole office to run anyway, and it always takes a long time until the dependencies in the makefiles are right... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Trying to solve a crasher in editeng unit test
On Thu, 2012-04-12 at 10:50 +0200, Stephan Bergmann wrote: > On 04/11/2012 10:44 PM, Kohei Yoshida wrote: > > On Wed, 2012-04-11 at 21:29 +0100, Caolán McNamara wrote: > >> On Wed, 2012-04-11 at 15:56 -0400, Kohei Yoshida wrote: > >>> Hey there, > >>> > >>> I'm trying to set up a new unit test for the edit engine core, but > >>> struggling with one crasher. > >> > >> http://cgit.freedesktop.org/libreoffice/core/commit/?id=6089be1a7a17ae849d8793520e9d8d36296ed5cf > >> should get you closer anyway, and into a more "mundane" crash with > >> SfxItemPools > > > > Thanks a lot. This helps. > > Hopefully any fix of yours will also fix the following problem: My > local --enable-dbgutil "make check" build keeps failing with a crash in > sw_subsequent_rtftok. Valgrind gives Crap. Maybe a unit test in editeng wasn't such a good idea after all. Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Trying to solve a crasher in editeng unit test
On 04/11/2012 10:44 PM, Kohei Yoshida wrote: On Wed, 2012-04-11 at 21:29 +0100, Caolán McNamara wrote: On Wed, 2012-04-11 at 15:56 -0400, Kohei Yoshida wrote: Hey there, I'm trying to set up a new unit test for the edit engine core, but struggling with one crasher. http://cgit.freedesktop.org/libreoffice/core/commit/?id=6089be1a7a17ae849d8793520e9d8d36296ed5cf should get you closer anyway, and into a more "mundane" crash with SfxItemPools Thanks a lot. This helps. Hopefully any fix of yours will also fix the following problem: My local --enable-dbgutil "make check" build keeps failing with a crash in sw_subsequent_rtftok. Valgrind gives ==32152== Invalid read of size 8 ==32152==at 0x12DC7689: SfxItemPool::GetDefaultItem(unsigned short) const (/svl/source/items/itempool.cxx:874) ==32152==by 0x12DC6058: SfxItemPool::Put(SfxPoolItem const&, unsigned short) (/svl/source/items/itempool.cxx:681) ==32152==by 0x12DC5E44: SfxItemPool::Put(SfxPoolItem const&, unsigned short) (/svl/source/items/itempool.cxx:663) ==32152==by 0x12DDD519: SfxItemSet::Put(SfxPoolItem const&, unsigned short) (/svl/source/items/itemset.cxx:609) ==32152==by 0x213CB7E5: SfxItemSet::Put(SfxPoolItem const&) (/solver/unxlngx6/inc/svl/itemset.hxx:150) ==32152==by 0x214DDDA4: sdr::properties::TextProperties::ForceDefaultAttributes() (/svx/source/sdr/properties/textproperties.cxx:384) ==32152==by 0x214DBC82: sdr::properties::DefaultProperties::GetObjectItemSet() const (/svx/source/sdr/properties/defaultproperties.cxx:94) ==32152==by 0x215A02D1: SdrObject::GetObjectItemSet() const (/svx/source/svdraw/svdobj.cxx:1981) ==32152==by 0x215FB757: SdrTextObj::GetTextLeftDistance() const (/svx/source/svdraw/svdotext.cxx:1792) ==32152==by 0x2161D645: SdrTextObj::NbcResize(Point const&, Fraction const&, Fraction const&) (/svx/source/svdraw/svdotxtr.cxx:125) ==32152==by 0x215ED66E: SdrPathObj::NbcResize(Point const&, Fraction const&, Fraction const&) (/svx/source/svdraw/svdopath.cxx:2370) ==32152==by 0x215EDF95: SdrPathObj::NbcSetSnapRect(Rectangle const&) (/svx/source/svdraw/svdopath.cxx:2466) ==32152==by 0x2159F3A1: SdrObject::SetSnapRect(Rectangle const&) (/svx/source/svdraw/svdobj.cxx:1687) ==32152==by 0x217086D4: SvxDrawPage::_CreateSdrObject(com::sun::star::uno::Reference const&) (/svx/source/unodraw/unopage.cxx:518) ==32152==by 0x2185BF74: SvxFmDrawPage::_CreateSdrObject(com::sun::star::uno::Reference const&) (/svx/source/form/fmdpage.cxx:102) ==32152==by 0x1F39D352: SwFmDrawPage::_CreateSdrObject(com::sun::star::uno::Reference const&) (/sw/source/core/unocore/unodraw.cxx:333) ==32152==by 0x21709CEF: SvxDrawPage::CreateSdrObject(com::sun::star::uno::Reference const&) (/svx/source/unodraw/unopage.cxx:850) ==32152==by 0x217071B0: SvxDrawPage::add(com::sun::star::uno::Reference const&) (/svx/source/unodraw/unopage.cxx:246) ==32152==by 0x1F39ED4F: SwXDrawPage::add(com::sun::star::uno::Reference const&) (/sw/source/core/unocore/unodraw.cxx:630) ==32152==by 0x255DA9D7: writerfilter::rtftok::RTFDocumentImpl::popState() (/writerfilter/source/rtftok/rtfdocumentimpl.cxx:3299) ==32152==by 0x25614308: writerfilter::rtftok::RTFTokenizer::resolveParse() (/writerfilter/source/rtftok/rtftokenizer.cxx:110) ==32152==by 0x255C4960: writerfilter::rtftok::RTFDocumentImpl::resolve(writerfilter::Stream&) (/writerfilter/source/rtftok/rtfdocumentimpl.cxx:548) ==32152==by 0x231E0722: RtfFilter::filter(com::sun::star::uno::Sequence const&) (/writerfilter/source/filter/RtfFilter.cxx:99) ==32152==by 0x1C359018: SfxObjectShell::ImportFrom(SfxMedium&, bool) (/sfx2/source/doc/objstor.cxx:2238) ==32152==by 0x1C351224: SfxObjectShell::DoLoad(SfxMedium*) (/sfx2/source/doc/objstor.cxx:730) ==32152==by 0x1C39E867: SfxBaseModel::load(com::sun::star::uno::Sequence const&) (/sfx2/source/doc/sfxbasemodel.cxx:1900) ==32152==by 0x1C3EC76C: SfxFrameLoader_Impl::load(com::sun::star::uno::Sequence const&, com::sun::star::uno::Reference const&) (/sfx2/source/view/frmload.cxx:611) ==32152==by 0x1A9C5EC5: framework::LoadEnv::impl_loadContent() (/framework/source/loadenv/loadenv.cxx:1160) ==32152==by 0x1A9C2696: framework::LoadEnv::startLoading() (/framework/source/loadenv/loadenv.cxx:418) ==32152==by 0x1A9C150C: framework::LoadEnv::loadComponentFromURL(com::sun::star::uno::Reference const&, com::sun::star::uno::Reference const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence const&) (/framework/source/loadenv/loadenv.cxx:184) ==32152==by 0x1A9FFCB0: framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence const&) (/framework/source/services/desktop.cxx:661) ==32152==by 0xCA59392: unotest::MacrosTest::loadFromDesktop(rtl::OUString const&) (/unotest/source/cpp/macros_test.cxx:53) ==32152==by 0xC61FB5E: RtfMode
Re: Trying to solve a crasher in editeng unit test
On Wed, 2012-04-11 at 21:29 +0100, Caolán McNamara wrote: > On Wed, 2012-04-11 at 15:56 -0400, Kohei Yoshida wrote: > > Hey there, > > > > I'm trying to set up a new unit test for the edit engine core, but > > struggling with one crasher. > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=6089be1a7a17ae849d8793520e9d8d36296ed5cf > should get you closer anyway, and into a more "mundane" crash with > SfxItemPools Thanks a lot. This helps. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Trying to solve a crasher in editeng unit test
On Wed, 2012-04-11 at 15:56 -0400, Kohei Yoshida wrote: > Hey there, > > I'm trying to set up a new unit test for the edit engine core, but > struggling with one crasher. http://cgit.freedesktop.org/libreoffice/core/commit/?id=6089be1a7a17ae849d8793520e9d8d36296ed5cf should get you closer anyway, and into a more "mundane" crash with SfxItemPools C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Trying to solve a crasher in editeng unit test
Hey there, I'm trying to set up a new unit test for the edit engine core, but struggling with one crasher. On the latest master, when you open editeng/qa/unit/core-test.cxx and uncomment line 132 and re-run make check, it fails with segmentation fault. The backtrace is attached. Anyone have any clue what could be the cause? Anyone seen anything similar in the past? Thanks, Kohei -- Kohei Yoshida, LibreOffice hacker, Calc Program received signal SIGSEGV, Segmentation fault. _copyConstructAnyFromData (pDestAny=0x77fca7e0, pSource=0x7fff7ec0, pType=0x61e050, pTypeDescr=0x0, acquire=0x72a78a60 , mapping=0x0) at /home/kyoshida/libo/master/cppu/source/uno/copy.hxx:260 260 pDestAny->pData = ::rtl_allocateMemory( pTypeDescr->nSize ); (gdb) bt #0 _copyConstructAnyFromData (pDestAny=0x77fca7e0, pSource=0x7fff7ec0, pType=0x61e050, pTypeDescr=0x0, acquire=0x72a78a60 , mapping=0x0) at /home/kyoshida/libo/master/cppu/source/uno/copy.hxx:260 #1 cppu::_copyConstructAny (pDestAny=0x77fca7e0, pSource=0x7fff7ec0, pType=0x61e050, pTypeDescr=0x0, acquire=0x72a78a60 , mapping=0x0) at /home/kyoshida/libo/master/cppu/source/uno/copy.hxx:371 #2 0x75738a2b in uno_type_any_assign (pDest=0x77fca7e0, pSource=0x7fff7ec0, pType=0x61e050, acquire=0x72a78a60 , release=) at /home/kyoshida/libo/master/cppu/source/uno/any.cxx:48 #3 0x72a9b6b8 in operator<<= (item=...) at /home/kyoshida/libo/master/solver/unxlngx6.pro/inc/com/sun/star/uno/Any.hxx:204 #4 utl::ConfigManager::acquireTree (item=...) at /home/kyoshida/libo/master/unotools/source/config/configmgr.cxx:198 #5 0x72a9ede4 in utl::ConfigManager::addConfigItem (this=0x72d886e0, item=...) at /home/kyoshida/libo/master/unotools/source/config/configmgr.cxx:224 #6 0x72a8d5b2 in utl::ConfigItem::ConfigItem (this=0x61dc10, rSubTree=, nSetMode=) at /home/kyoshida/libo/master/unotools/source/config/configitem.cxx:231 #7 0x72b046b6 in SvtSysLocaleOptions_Impl::SvtSysLocaleOptions_Impl (this=0x61dc10) at /home/kyoshida/libo/master/unotools/source/config/syslocaleoptions.cxx:167 #8 0x72b04cdb in SvtSysLocaleOptions::SvtSysLocaleOptions (this=0x61c548) at /home/kyoshida/libo/master/unotools/source/config/syslocaleoptions.cxx:474 #9 0x72b2b016 in SvtSysLocale_Impl::SvtSysLocale_Impl (this=) at /home/kyoshida/libo/master/unotools/source/misc/syslocale.cxx:63 #10 0x72b2b45d in SvtSysLocale::SvtSysLocale (this=) at /home/kyoshida/libo/master/unotools/source/misc/syslocale.cxx:103 #11 0x75121a92 in OnDemandLocaleDataWrapper (this=0x61d770, pEE=0x7fff8340, pItemPool=) at /home/kyoshida/libo/master/solver/unxlngx6.pro/inc/svl/ondemand.hxx:80 #12 ImpEditEngine::ImpEditEngine (this=0x61d770, pEE=0x7fff8340, pItemPool=) at /home/kyoshida/libo/master/editeng/source/editeng/impedit2.cxx:112 #13 0x750f4c82 in EditEngine::EditEngine (this=0x7fff8340, pItemPool=0x7fff8320) at /home/kyoshida/libo/master/editeng/source/editeng/editeng.cxx:115 #14 0x75fe2b0b in (anonymous namespace)::Test::testConstruction() () from /home/kyoshida/libo/master/workdir/unxlngx6.pro/LinkTarget/CppunitTest/libtest_editeng_core.so #15 0x77948f20 in CppUnit::TestCaseMethodFunctor::operator()() const () from /home/kyoshida/libo/master/solver/unxlngx6.pro/lib/libcppunit-1.12.so.1 #16 0x7793aee2 in CppUnit::DefaultProtector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) () from /home/kyoshida/libo/master/solver/unxlngx6.pro/lib/libcppunit-1.12.so.1 #17 0x77944223 in CppUnit::ProtectorChain::ProtectFunctor::operator()() const () from /home/kyoshida/libo/master/solver/unxlngx6.pro/lib/libcppunit-1.12.so.1 #18 0x779440d1 in CppUnit::ProtectorChain::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) () from /home/kyoshida/libo/master/solver/unxlngx6.pro/lib/libcppunit-1.12.so.1 #19 0x7795321c in CppUnit::TestResult::protect(CppUnit::Functor const&, CppUnit::Test*, std::basic_string, std::allocator > const&) () from /home/kyoshida/libo/master/solver/unxlngx6.pro/lib/libcppunit-1.12.so.1 #20 0x779489d6 in CppUnit::TestCase::run(CppUnit::TestResult*) () from /home/kyoshida/libo/master/solver/unxlngx6.pro/lib/libcppunit-1.12.so.1 #21 0x779495f0 in CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) () from /home/kyoshida/libo/master/solver/unxlngx6.pro/lib/libcppunit-1.12.so.1 #22 0x77949472 in CppUnit::TestComposite::run(CppUnit::TestResult*) () from /home/kyoshida/libo/master/solver/unxlngx6.pro/lib/libcppunit-1.12.so.1 #23 0x779495f0 in CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) () from /home/kyoshida/libo/master/solver/unxlngx6.pro/lib/libcppunit-1.12.so.1 #24 0x77949472 in CppUnit::TestComposite::run(CppUnit::TestResult*) () from /home/kyoshida/libo/m
