Bug 87028 - Crash Writer with RTF from Oracle Reports
Summary: Crash Writer with RTF from Oracle Reports
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.4.1 release
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace
Depends on:
Blocks:
 
Reported: 2014-12-05 10:57 UTC by Sanel Zukan
Modified: 2015-02-08 20:59 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Crash stacktrace (4.01 KB, text/plain)
2014-12-05 10:57 UTC, Sanel Zukan
Details
Crash stacktrace from debug LO (6.55 KB, text/plain)
2014-12-05 17:42 UTC, Sanel Zukan
Details
4.3.4 LO debug stacktrace (6.66 KB, text/plain)
2014-12-06 15:20 UTC, Sanel Zukan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sanel Zukan 2014-12-05 10:57:01 UTC
Created attachment 110488 [details]
Crash stacktrace

Hi guys,

I'm having this bug for last couple of version. I'm receiving bank statement in RTF format, generated from Oracle Reports, and each time I tried to open it with Writer, it will crash it down.

In attachment is a stacktrace I was able to get, however, due the secrecy of the matter I'm not able to provide a document itself. LibreOffice version is 4.3.4, but the crash was present in most of 4.x series.

I'll be happy to give you more details if necessary. Thanks!
Comment 1 Sanel Zukan 2014-12-05 10:58:24 UTC
Forgot to mention, unrtf tool will open it without problems.
Comment 2 Julien Nabet 2014-12-05 11:36:57 UTC
Do you reproduce this with a brand new report (so without confidential elements in it)?
On which Linux distribution are you?
Would it possible you install LO debug package (in Debian and derivates like Ubuntu it's "libreoffice-dbg") and retrieve a more useful backtrace?
Comment 3 Sanel Zukan 2014-12-05 17:42:28 UTC
Created attachment 110496 [details]
Crash stacktrace from debug LO
Comment 4 Sanel Zukan 2014-12-05 17:45:49 UTC
Yes, I can reproduce this on all reports, including the new one I got this morning.

> On which Linux distribution are you?

Slackware 14.1 x86_64, but can reproduce it on Ubuntu 14.4 LTS with LO 4.2.7.2.

I added stacktrace from libreoffice-dbg package, installed on Ubuntu.
Comment 5 Julien Nabet 2014-12-05 20:14:42 UTC
Thank you for your bt, I put it at NEW.
If you have some time, it would be interesting to have a bt with symbols with LO 4.3.4 (see https://launchpad.net/~libreoffice/+archive/ubuntu/ppa).
Comment 6 Sanel Zukan 2014-12-06 15:20:41 UTC
Created attachment 110510 [details]
4.3.4 LO debug stacktrace

Sure, here is stacktrace from 4.3.4 debug version.
Comment 7 Jean-Baptiste Faure 2014-12-06 16:54:08 UTC
Please could you try another Oracle report in RTF format like here: bug 59547.
With this file I do not have a crash with version 4.4.0.0.beta2+ built at home under Ubuntu 14.10 x86-64.

Bets regards. JBF
Comment 8 Sanel Zukan 2014-12-06 20:49:50 UTC
Just tried it and it is opening without problems. Although after couple of scrolls, it became unresponsive due large CPU usage, just as described in the report.
Comment 9 Julien Nabet 2014-12-06 21:17:09 UTC
Thank you Sanel for this new feedback
it seems the bt could be here line 4532 (4520 + 12 from d74f3f2a1b98fbcba9e5490b6d790fa40d8b863d, the other commits are after this block):
4529     case RTF_DPPTY:
4530     {
4531         RTFDrawingObject& rDrawingObject = m_aStates.top().aDrawingObject;
4532         if (rDrawingObject.aPolyLinePoints.hasElements())
4533         {

Miklos: could rDrawingObject.aPolyLinePoints or even rDrawingObject be NULL? (and so should be checked)
Of course, the root cause must be elsewhere.
Comment 10 Caolán McNamara 2015-02-05 11:38:26 UTC
I don't think we can do anything about this unless we have an example. If you want to email an example to me I can have a look into it for you.
Comment 11 Sanel Zukan 2015-02-05 17:43:49 UTC
I'm really sad to see this state: you are faster to make this task invalid than to proceed to *at least* try to solve it.

Have you tried to get more information? Do you need more information? Have you tried to contact me in the past without success and decided to mark it as invalid? Do you have some references where is shown that you tried everything, after long discussion with other participants here?

I really don't want to be rude here, especially since other devs were really helpful, but I doubt RH would like to see that LO is not able to parse seemingly complex RTF without crashing the whole suite.

What you want me to do then? Sit down and debug myself, maybe fix this thing and you receive all praises then? I mean, at least you *could* try to help here...

BTW. requesting me to send you confidential document, so *you can look at it*, really tells me how truly you want to solve this thing.
Comment 12 Noel Grandin 2015-02-06 07:51:38 UTC
@Sanel, so edit the document to remove the confidential bits, replacing the text with nonsense, but leaving enough stuff so it still crashes LO.

Then send that. It's not very much to ask.
Comment 13 Julien Nabet 2015-02-08 20:59:56 UTC
(In reply to Sanel Zukan from comment #11)
> I'm really sad to see this state: you are faster to make this task invalid
> than to proceed to *at least* try to solve it.
Sometimes the bt isn't sufficient, we need to reproduce the bug. In this case,  it's quite normal to have the document.

> Have you tried to get more information? Do you need more information? Have
> you tried to contact me in the past without success and decided to mark it
> as invalid? Do you have some references where is shown that you tried
> everything, after long discussion with other participants here?
There are too much bugs badfully and dev time is scarce resource.

> ...

> What you want me to do then? Sit down and debug myself, maybe fix this thing
> and you receive all praises then? I mean, at least you *could* try to help
> here...
Caolan suggested to email your file in private, that's all.

> BTW. requesting me to send you confidential document, so *you can look at
> it*, really tells me how truly you want to solve this thing.
I think you judge him a little too fast, just take a look at this:
http://cgit.freedesktop.org/libreoffice/core/log/?qt=author&q=caolan
So if he proposed you to take a look to your file, he meaned it.

Now if you want to debug yourself this bug, you can start here https://wiki.documentfoundation.org/Development, then submit a patch and if it's ok, your commit will show your name (so you will get the praises :-))