Created attachment 103461 [details]
With a spreadsheet open, picking Format:Page... produceds a spinning beach ball for a few seconds, then crash. This appears to affect most 4.0.0.alpha0 nightlies incl. the one I just pulled yesterday. It also affects the PPC built bu Doug Mencken/OSU OSL.
I will append a crash log (zipped).
Not reproducible, tested using Mac OSX 10.9 with LibreOffice 220.127.116.11 rc. Also not repro on Ubuntu 14.04.
(In reply to comment #1)
> Not reproducible, tested using Mac OSX 10.9 with LibreOffice 18.104.22.168 rc.
> Also not repro on Ubuntu 14.04.
No surprise: The bug is triggered in Lo 22.214.171.124.alpha0 on OS X 10.6.8. That is, Lo four-point-four. It is NOT present in 126.96.36.199 (last 4.3 I have). Very reproducible with Libreoffice nightly:
TinderBox: MacOSX-x86@49-TDF, Branch:master, Time: 2014-07-11_18:39:38
I will check against a more recent lightly soon.
(In reply to comment #2)
> (In reply to comment #1)
> No surprise: The bug is triggered in Lo 188.8.131.52.alpha0 on OS X 10.6.8. That
> is, Lo four-point-four. It is NOT present in 184.108.40.206 (last 4.3 I have).
Thanks for being friendly and not mentioning you can't reproduce this in 4.3. I only have access to 220.127.116.11 test setup right now, so I left the comment I can't in 18.104.22.168. Not more, not less. Accept it, if you don't mention it, someone else will. Not sure where you problem starts with that? Feel free to discuss this on the mailinglist or on IRC.
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > No surprise: The bug is triggered in Lo 22.214.171.124.alpha0 on OS X 10.6.8. That
> > is, Lo four-point-four. It is NOT present in 126.96.36.199 (last 4.3 I have).
> Thanks for being friendly and not mentioning you can't reproduce this in
> 4.3. I only have access to 188.8.131.52 test setup right now, so I left the
> comment I can't in 184.108.40.206. Not more, not less. Accept it, if you don't
> mention it, someone else will. Not sure where you problem starts with that?
> Feel free to discuss this on the mailinglist or on IRC.
My apologies; in the OP I explicitly mention the version where I found the bug. But yes, I could have mentioned that it appears to be a new one introduced with the 4.4 version and does not appear to be present in 4.3 (or 4.2, for that matter). Also note that I found it in the Spreadsheet module only. It is not present in the Writer module. I do not know about the other modules.
My main aim is that it should be known to those working on 4.4, which otherwise seems to be quite a nice version (at least for me so far), and that it does not get closed before being addressed. It is a rather serious issue.
I don't have access to OS X newer than 10.6.8 so cannot comment on those systems. Bugzilla does not seem to allow to specify versions of OS X.
(In reply to comment #4)
> My apologies;
No worries ;-). More than accepted.
> It is a rather serious issue.
It is, therefore we have to try to narrow the range and make sure where it is introduced.
> I don't have access to OS X newer than 10.6.8 so cannot comment on those
> systems. Bugzilla does not seem to allow to specify versions of OS X.
Sure, will test this bug later this week :-).
Reproducible, tested using Mac OSX 10.9 with LibreOffice Version: 220.127.116.11.alpha0+ Build ID: 998ab5c405963accf47afc69a6bf04e045f6f71f
TinderBox: MacOSX-x86@49-TDF, Branch:master, Time: 2014-07-22_03:13:14
Marking as NEW
I confirm this regression.
It's probably caused by commit 7d9bb549d ( https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=7d9bb549d498d6beed2c4050c402d09643febdfa ),
where we have svx/source/unodraw/unobrushitemhelper.cxx with that setSvxBrushItemAsFillAttributesToTargetSet method, which fails on one of rToSet.Put.
0 libsvllo.dylib 0x010df254 SfxItemPool::Put(SfxPoolItem const&, unsigned short) + 612
1 libsvllo.dylib 0x010ea64c SfxItemSet::Put(SfxPoolItem const&, unsigned short) + 476
2 libsvxcorelo.dylib 0x2029d6cc setSvxBrushItemAsFillAttributesToTargetSet(SvxBrushItem const&, SfxItemSet&) + 2396
It affects not only x86. (Changed to "All".)
It happens every time.
Maybe set to "blocker"?
@@ -132,6 +132,7 @@ void setSvxBrushItemAsFillAttributesToTargetSet(const SvxBrushItem& rBrush, SfxI
// GPOS_NONE == rBrush.GetGraphicPos() && 0xff == rBrush.GetColor().GetTransparency(),
@@ -146,8 +147,11 @@ void setSvxBrushItemAsFillAttributesToTargetSet(const SvxBrushItem& rBrush, SfxI
const Color aColor(rBrush.GetColor().GetRGBColor());
0 libsvxcorelo.dylib 0x16638ac4 drawinglayer::primitive2d::createNewSdrFillAttribute(SfxItemSet const&) + 100
1 libsvxcorelo.dylib 0x165e8d90 drawinglayer::attribute::SdrAllFillAttributesHelper::SdrAllFillAttributesHelper(SfxItemSet const&) + 96
2 libcuilo.dylib 0x1886fb3c SvxPageDescPage::ResetBackground_Impl(SfxItemSet const&) + 2444
3 libcuilo.dylib 0x188705dc SvxPageDescPage::Reset(SfxItemSet const*) + 1996
4 libsfxlo.dylib 0x05283528 SfxTabDialog::ActivatePageHdl(TabControl*) + 1048
5 libsfxlo.dylib 0x05283974 SfxTabDialog::Start_Impl() + 628
6 libsfxlo.dylib 0x05283b0c SfxTabDialog::Execute() + 44
7 libscuilo.dylib 0x14c7b1cc ScAbstractTabDialog_Impl::Execute() + 28
8 libsclo.dylib 0x154859ac ScDocShell::ExecutePageStyle(SfxViewShell&, SfxRequest&, short) + 316
9 libsclo.dylib 0x157a176c ScTabViewShell::Execute(SfxRequest&) + 1612
So it's cui/source/tabpages/page.cxx or underlining design.
The same cui dialog works for writer. But writer pages have both footer, header (or absense of them). They might be filled, even with transparent gradient, yeah, it's cool.
But is it fully applicable to Calc pages (given that the same @@ -1280,7 +1280,7 @@ void SvxPageDescPage::ResetBackground_Impl(const SfxItemSet& rSet) is used)?
I know this patch is adopted from Apache, but anyway...
Miklos: following Douglas' comment (https://bugs.freedesktop.org/show_bug.cgi?id=81756#c7), I thought you might be interested in this one.
*** This bug has been marked as a duplicate of bug 81496 ***