Bug 71130 - Report-Builder: Report with charts gives immediate segfault
Summary: Report-Builder: Report with charts gives immediate segfault
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.2.0.0.alpha0+ Master
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Lionel Elie Mamane
URL:
Whiteboard: bibisectednewer target:4.2.0
Keywords: regression
Depends on:
Blocks:
 
Reported: 2013-11-01 16:55 UTC by Robert Großkopf
Modified: 2013-11-08 02:20 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Two reports in the database. The report with a chart let LO crash immediately. (20.68 KB, application/vnd.oasis.opendocument.base)
2013-11-01 16:55 UTC, Robert Großkopf
Details
bt on master (16.92 KB, text/plain)
2013-11-01 20:28 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2013-11-01 16:55:11 UTC
Created attachment 88492 [details]
Two reports in the database. The report with a chart let LO crash immediately.

Open the attached Database.
There are two reports in this database. One Report with a chart, the other (same content) without a chart.
When trying to open the report with the chart LO since 4.2 crashes immediately. 
When opening the same report without a chart it works well.

I have tried this with many different reports - all reports with charts fail and let LO 4.2 crash immediately. It isn't possible to edit such a report in LO 4.2 - it produces the same crash.

Then I tried to create a new report in LO 4.2 with a chart. The creation works, but the first start of the report let LO crash immediately.
Comment 1 Julien Nabet 2013-11-01 20:28:51 UTC
Created attachment 88510 [details]
bt on master

On pc Debian x86-64 with master sources updated yesterday, I reproduced the problem.
I attached bt

(I must say I use enable-dbgutil)
Comment 2 Julien Nabet 2013-11-01 20:43:06 UTC
Lionel/Stephan: I attached a bt showing Uno part.
Comment 3 Julien Nabet 2013-11-01 22:12:35 UTC
By trying to apply what http://stackoverflow.com/questions/14148380/how-to-troubleshoot-undefined-reference-to-non-virtual-thunk-to indicated, I had this:
julien@julienPC:~/compile-libreoffice/libo/instdir/unxlngx6/program$ nm -po *.so | c++filt | grep 'rptui::OCustomShape::~OCustomShape()'  | grep -v ' U ' | more
librptlo.so:000000000011eba6 T rptui::OCustomShape::~OCustomShape()
librptlo.so:000000000011eb99 T non-virtual thunk to rptui::OCustomShape::~OCustomShape()
librptlo.so:000000000011eae2 T rptui::OCustomShape::~OCustomShape()
librptlo.so:000000000011eae2 T rptui::OCustomShape::~OCustomShape()
librptlo.so:000000000011ebcc T non-virtual thunk to rptui::OCustomShape::~OCustomShape()

Now I'm a bit stuck :-(
Comment 4 Terrence Enger 2013-11-02 17:32:06 UTC
I do not see the crash in the latest version of 4.0+ bibisect (commit 86cbe18).
Comment 5 Stephan Bergmann 2013-11-04 08:27:23 UTC
The backtrace in attachment 88510 [details] very much looks like either the SdrOle2Obj instance in frame 4 (or at least its mpImpl) is already destroyed and its memory overwritten, or the static_cast in frame 5 SvxOle2Shape::setPropertyValueImpl case OWN_ATTR_PERSISTNAME is wrong.
Comment 6 Lionel Elie Mamane 2013-11-08 01:18:01 UTC
(In reply to comment #5)
> The backtrace in attachment 88510 [details] (...) very much looks
> the static_cast in frame 5
> SvxOle2Shape::setPropertyValueImpl case OWN_ATTR_PERSISTNAME is wrong.

Yes, that's it. It is a rptui::OCustomShape and the class inheritance graph is

rptui::OCustomShape -> SdrObjCustomShape -> SdrTextObj

SdrOle2Obj -> SdrRectObj -> SdrTextObj

Now, why didn't it crash in LibreOffice 4.0...
Comment 7 Lionel Elie Mamane 2013-11-08 01:59:24 UTC
(In reply to comment #6)
> Now, why didn't it crash in LibreOffice 4.0...

rptui::OObjectBase::createObject calls OObjectBase::getObjectType
which returns different values in 4.1 and 4.2:

4.1: OBJ_OLE2
4.2: OBJ_CUSTOMSHAPE

Which leads rptui::OObjectBase::createObject to create different objects...

getObjectType in turn calls reportdesign::OShape::supportsService
which has changed.
Comment 8 Commit Notification 2013-11-08 02:20:15 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

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

fdo#71130 pretend to support service m_sServiceName



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.