Bug 81147 - Assertion failure when right-clicking and selecting Area... on a graphic in Writer
Summary: Assertion failure when right-clicking and selecting Area... on a graphic in W...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Libreoffice (show other bugs)
Version: 4.4.0.0.alpha0+ Master
Hardware: Other All
: highest blocker
Assignee: Caolán McNamara
QA Contact:
URL:
Whiteboard: target:4.4.0
Keywords:
: 80940 (view as bug list)
Depends on:
Blocks: mab4.4
  Show dependency treegraph
 
Reported: 2014-07-10 06:40 UTC by Tor Lillqvist
Modified: 2014-07-11 13:11 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
callgrind log file (4.02 KB, text/plain)
2014-07-10 09:05 UTC, Marina Latini
Details

Description Tor Lillqvist 2014-07-10 06:40:07 UTC
Open a Writer document, add a rectangle, right-click on it, select Area... It crashes with an ssertion failure: include/rtl/ref.hxx:166: reference_type *rtl::Reference<XColorList>::operator->() const [reference_type = XColorList]: Assertion `m_pBody != 0' failed
Comment 1 Tor Lillqvist 2014-07-10 08:44:47 UTC
Not surprisingly, happens on OS X too, so changing Platform field to All.
Comment 2 Marina Latini 2014-07-10 09:05:27 UTC
Created attachment 102525 [details]
callgrind log file

Callgrind log file
Comment 3 Marina Latini 2014-07-10 09:27:33 UTC
Confirmed on:
* Version: 4.4.0.0.alpha0+
* Build ID: 3fdd4f069d5436cf39708004af7fda8175fbc4c2
* TinderBox: Linux-rpm_deb-x86_64@46-TDF, 
* Branch:master, Time: 2014-07-09_02:51:53
* OS: Ubuntu 14.04 x86_64 

Status New
Importance -> highest - blocker
According to "Bug Priority Triage Flowchart Suggestions" I set the importance to blocker and highest because the bug happens every time a user uses this dialog and causes a crash.

A valgrind out here: https://www.dropbox.com/s/sin0vhjwm7zmesa/callgrind.out.3329.gz
Comment 4 Douglas Mencken 2014-07-10 10:44:23 UTC
I confirm it too. But on my side it crashes inside XPropertyList::Count() called by SvxColorTabPage::UpdateModified():

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x000000000000002c
Crashed Thread:  0

Thread 0 Crashed:
0   libsvxcorelo.dylib                0x06239df4 XPropertyList::Count() const + 20
1   libcuilo.dylib                    0x3366b9d8 SvxColorTabPage::UpdateModified() + 24
2   libcuilo.dylib                    0x3366b9d8 SvxColorTabPage::UpdateModified() + 24
3   libcuilo.dylib                    0x33670714 SvxColorTabPage::Reset(SfxItemSet const*) + 516
4   libsfxlo.dylib                    0x00c72558 SfxTabDialog::ActivatePageHdl(TabControl*) + 1048
5   libvcllo.dylib                    0x02fc841c TabControl::calculateRequisition() const + 140
6   libvcllo.dylib                    0x02fc85a4 TabControl::GetOptimalSize() const + 20
7   libvcllo.dylib                    0x02f540d8 Window::get_ungrouped_preferred_size() const + 152
8   libvcllo.dylib                    0x02f56520 Window::get_preferred_size() const + 32
...

* it fails on (XPropertyList*) this, where "this" is already NULL, so let's dig up to the caller
* void SvxColorTabPage::UpdateModified() <cui/source/tabpages/tpcolor.cxx:585> --
  bool bEnable = pColorList->Count(); <---- pColorList is already NULL here
* `long XPropertyList::Count() const' returns `maList.size();' but it's called as `bool bEnable = pColorList->Count();'
  to do things like m_pBtnModify->Enable( bEnable ); etc.
* since when are sizes true/false?!
* why pColorList isn't initialized in ctor? but only in SvxColorTabPage::Update,
  which is called on bottom of strangely titled IMPL_LINK_NOARG(SvxColorTabPage, ClickLoadHdl_Impl)
* maybe the logic was: `bool bEnable = false; if (pColorList) { if (pColorList->Count() > 0) { bEnable = true; } }' ?
Comment 5 Terrence Enger 2014-07-10 12:34:27 UTC
*** Bug 80940 has been marked as a duplicate of this bug. ***
Comment 6 Terrence Enger 2014-07-10 12:36:40 UTC
Bug 80940 sounds like the segfault problem reported here.  That bug
has a backtrace attached.
Comment 7 Tor Lillqvist 2014-07-10 12:39:02 UTC
I didn't realize I need to attach a backtrace for a crasher in master; by definition, anybody that is going to debug this builds master, and can get a backtrace then in the debugger. Or what am I missing?
Comment 8 Terrence Enger 2014-07-10 13:06:31 UTC
Tor,

I am not suggesting that you are missing anything.

I tend to attach backtraces to bug reports mostly because I lack the
knowledge to do anything more useful.  Thet said, they may help
somebody else working on bug reports, not necessarily a developer, to
determine "looks similar" or "looks different".  Assertions are a bit
different in that they are evident only in debug builds.

Maybe I am adding more noise than useful information.  Guidance
welcome.

Thanks,
Terry.
Comment 9 Commit Notification 2014-07-11 13:11:18 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=86de78ce5076ed00c6ad19eae7ab6da7c7a91196

Related: fdo#81147 check if colorlist is valid



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 10 Commit Notification 2014-07-11 13:11:31 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=76631b6b9147dd83006a6382441d311f668f3286

Resolves: fdo#81147 fix mismatching drawlayer and docshell colorlists



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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.