crashes on concurrent setModel() and getDispatchForURL() in
JunitTest_chart2_unoapi:
Thread 13:
7 in (anonymous namespace)::Frame::isActionLocked (this=0x2b66c0e4a090) at /home/tinderbox/master/framework/source/services/frame.cxx:2596
8 in (anonymous namespace)::Frame::close (this=0x2b66c0e4a090, bDeliverOwnership=0 '\000') at /home/tinderbox/master/framework/source/services/frame.cxx:1772
9 in chart::ChartController::notifyClosing (this=0x2b668ae41058, rSource=...) at /home/tinderbox/master/chart2/source/controller/main/ChartController.cxx:872
10 in apphelper::CloseableLifeTimeManager::impl_doClose (this=0x2b669a0b1d08) at /home/tinderbox/master/chart2/source/tools/LifeTime.cxx:360
11 in apphelper::CloseableLifeTimeManager::g_close_endTryClose_doClose (this=0x2b669a0b1d08) at /home/tinderbox/master/chart2/source/tools/LifeTime.cxx:311
12 in chart::ChartModel::close (this=0x2b669a0b1c28, bDeliverOwnership=1 '\001') at /home/tinderbox/master/chart2/source/model/main/ChartModel.cxx:659
Thread 1:
4 in std::__debug::map<rtl::OUString, com::sun:⭐:uno::Reference<com::sun:⭐:frame::XDispatch>, std::less<rtl::OUString>, std::allocator<std::pair<rtl::OUString const, com::sun:⭐:uno::Reference<com::sun:⭐:frame::XDispatch> > > >::find (this=0x2b668ae41248, __x=...) at /usr/include/c++/4.8.3/debug/map.h:382
No locals.
5 in chart::CommandDispatchContainer::getDispatchForURL (this=0x2b668ae41248, rURL=...) at /home/tinderbox/master/chart2/source/controller/main/CommandDispatchContainer.cxx:80
6 in chart::ChartController::queryDispatch (this=0x2b668ae41058, rURL=..., rTargetFrameName=...) at /home/tinderbox/master/chart2/source/controller/main/ChartController.cxx:1003
No locals.
7 in framework::DispatchProvider::implts_queryFrameDispatch (this=0x2b66a3fd21e8, xFrame=..., aURL=..., sTargetFrameName=..., nSearchFlags=0) at /home/tinderbox/master/framework/source/dispatch/dispatchprovider.cxx:374
8 in framework::DispatchProvider::queryDispatch (this=0x2b66a3fd21e8, aURL=..., sTargetFrameName=..., nSearchFlags=0) at /home/tinderbox/master/framework/source/dispatch/dispatchprovider.cxx:111
9 in framework::InterceptionHelper::queryDispatch (this=0x2b668a61bc08, aURL=..., sTargetFrameName=..., nSearchFlags=0) at /home/tinderbox/master/framework/source/dispatch/interceptionhelper.cxx:78
10 in (anonymous namespace)::Frame::queryDispatch (this=0x2b66c0e4a090, aURL=..., sTargetFrameName=..., nSearchFlags=0) at /home/tinderbox/master/framework/source/services/frame.cxx:2227
11 in svt::ToolboxController::bindListener (this=0x2b66c0f72740) at /home/tinderbox/master/svtools/source/uno/toolboxcontroller.cxx:529
12 in svt::ToolboxController::update (this=0x2b66c0f72740) at /home/tinderbox/master/svtools/source/uno/toolboxcontroller.cxx:232
13 in framework::ToolBarManager::UpdateControllers (this=0x2b669a0a1728) at /home/tinderbox/master/framework/source/uielement/toolbarmanager.cxx:440
14 in framework::ToolBarManager::AsyncUpdateControllersHdl (this=0x2b669a0a1728) at /home/tinderbox/master/framework/source/uielement/toolbarmanager.cxx:2110
15 in framework::ToolBarManager::LinkStubAsyncUpdateControllersHdl (pThis=0x2b669a0a1728, pCaller=0x2b669a0a1890) at /home/tinderbox/master/framework/source/uielement/toolbarmanager.cxx:2097
16 in Link::Call (this=0x2b669a0a18b0, pCaller=0x2b669a0a1890) at /home/tinderbox/master/include/tools/link.hxx:139
17 in Timer::Timeout (this=0x2b669a0a1890) at /home/tinderbox/master/vcl/source/app/timer.cxx:276
Change-Id: I17ef63db8f7c288460e00031e8e8a5c3e4d086b3
Sadly cannot forward declare "struct {...} TimeValue;".
rtl/(u)?string.hxx still include sal/log.hxx but removing osl/diagnose.h
was painful enough for now...
Change-Id: Id41e17f3870c4f24c53ce7b11f2c40a3d14d1f05
and make the two categories of constants non-overlapping, we
really don't need to risk confusion in order to save 6 bits in
a data structure like this.
Change-Id: I2251195d8e45ed04e2a89e47ae9c3e52cf0475c0
they are largely unnecessary these days, since our OUString infrastructure
gained optimised handling for static char constants.
Change-Id: I07f73484f82d0582252cb4324d4107c998432c37
The VAxisBase::m_xNumberFormatsSupplier refers to the ChartModel itself,
and apparently that is a cyclic reference. Naively using the
ChartModel's m_xNumberFormatsSupplier in
ChartView::impl_createDiagramAndContent() because it will later be passed
to AxisHelper::getExplicitNumberFormatKeyForAxis(), which expects to be
able to convert it to a ChartModel.
Since passing around the ChartModel as an XNumberFormattingSupplier is
sort of un-intuitive anyway, refactor some methods to use XChartDocument
instead, and only create the VPolarAxis / VCartesianAxis with the
ChartModel's m_xNumberFormatsSupplier.
The drawback is that if ChartModel::attachNumberFormatsSupplier()
is called after ChartView::update() has created the axes, it may not
have an effect on them; not sure if that is a real or hypothetical
problem.
Change-Id: Ib5f0d5882b85adaf44f80e086f19178b3e64882f
there were three of these, not just one
i.e. see also
commit 276a051ef5dc144a202633779259a4ecd43c81a8
Date: Sun Oct 5 13:05:04 2014 -0500
coverity#1223085 Unchecked return value
Change-Id: I07ee033ae31a346a08f68a6edfa480505fe6c11a
* Added rational util functions used by Fraction class not
available in the boost::rational class.
* Replaced usage of Fraction by boost::rational<long>
* Removed code that relies on:
1. fraction.IsValid() -- rational only allow valid values, ie
denominator() != 0
2. rational.denominator() == 0 -- always false
3. rational.denominator() < 0 -- always false but implementation
detail: http://www.boost.org/doc/libs/release/libs/rational/rational.html#Internal%20representation
* Simplified code that relies on:
1. rational.denominator() != 0 -- always true
* BUGS EXIST because Fraction allows the creation of invalid values but
boost::rational throws the exception boost::bad_rational
Change-Id: I84970a4956afb3f91ac0c8f726547466319420f9
Reviewed-on: https://gerrit.libreoffice.org/11551
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
...to gain further confidence in the claim "that none of the existing
code tries to uses combinations of these enum values"
(d92602c5b13d0a60439d86c5a033d124178726ca "more fixes for SfxItemState")
Change-Id: I987922d945e8738e38adfde83b869adf3ff35b13
Reviewed-on: https://gerrit.libreoffice.org/11384
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
In commit 88a874fc "convert SfxItemState constants to a proper enum"
I made some mistakes in converting bitwise logic to boolean logic.
I fixed one of those places in commit 7ad83656 "fix bitwise->logic
conversion in SfxItemState commit"
This commit fixes the other places where I converted bitwise to normal
boolean logic. I also validated that none of the existing code tries to
uses combinations of these enum values.
This commit also introduces an exception-throwing check in the one place
where the enum is explicitly cast to make sure that no combinations
sneak in.
Change-Id: I545f7d17b76c4fd999078867caec314e83ffe165
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
...similar to what has been done for svx/sdtmfitm.hxx in
68969cc61adecac481ae9656978ef952f435b310 "Consistency around SdrMetricItem."
Change-Id: I7f2348d82c76f6f231e34f0dfc4b6ee6fddffe55
...similar to what has been done for svx/sdtmfitm.hxx in
68969cc61adecac481ae9656978ef952f435b310 "Consistency around SdrMetricItem."
Change-Id: If26ab3229871d2d6a7e4e7e8f79f4cb927b96930
...similar to what has been done for svx/sdtmfitm.hxx in
68969cc61adecac481ae9656978ef952f435b310 "Consistency around SdrMetricItem."
Change-Id: I3253b4cc5657a7d6b960ee892584109d373eed3d
...similar to what has been done for svx/sdtmfitm.hxx in
68969cc61adecac481ae9656978ef952f435b310 "Consistency around SdrMetricItem."
Change-Id: I3193eab34a34c051002adeedd8b368e26f55f7a3
