Download it now!
Bug 61309 - FILEOPEN: Open particular docx result in crash (assertion failure)
Summary: FILEOPEN: Open particular docx result in crash (assertion failure)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.0.0.alpha0+ Master
Hardware: Other Linux (All)
: medium critical
Assignee: Michael Stahl (CIB)
URL:
Whiteboard: BSA target:4.1.0
Keywords: regression
Depends on:
Blocks:
 
Reported: 2013-02-22 19:39 UTC by Jorendc
Modified: 2013-02-28 13:24 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
backtrace log (32.18 KB, text/x-log)
2013-02-22 19:39 UTC, Jorendc
Details
bt + console logs on master (24.14 KB, text/plain)
2013-02-23 17:53 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jorendc 2013-02-22 19:39:39 UTC
Created attachment 75362 [details]
backtrace log

Download attachment of Bug 61305 (Attachment link = https://bugs.freedesktop.org/attachment.cgi?id=75354 )

Open this file using LibreOffice master [Version 4.1.0.0.alpha0+ (Build ID: 99501a839f6d777c24bc9210787fd14dc3aad67)] -> Crash. Tested using Linux Mint 14 x64.

Terminal output:

warn:writerfilter:314:1:writerfilter/source/dmapper/DomainMapper_Impl.cxx:435: no context of type 1 available
warn:svx.sdr:314:1:svx/source/svdraw/svdobj.cxx:2935: SdrObject::impl_setUnoShape: still having impl. pointer to dead object!
warn:legacy.osl:314:1:oox/source/vml/vmlshapecontainer.cxx:47: lclMapShapesById - shape identifier already used 
warn:svx.sdr:314:1:svx/source/svdraw/svdobj.cxx:2935: SdrObject::impl_setUnoShape: still having impl. pointer to dead object!
soffice.bin: /home/joren/core/sw/source/core/txtnode/ndtxt.cxx:3763: void SwTxtNode::SetAttrListLevel(int): Assertion `false' failed.

Operating System: Linux (Other)
Version: 4.1.0.0.alpha0+ Master
Last worked in: 4.0.1.1 rc
Comment 1 Jorendc 2013-02-22 19:45:29 UTC
Following [1] I mark this as 'medium critical'

https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
Comment 2 Jorendc 2013-02-22 19:47:31 UTC
I see in my own backtrace following Dutch sentence: 

Program received signal SIGABRT, Aborted.
0x00007ffff6cd1425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	../nptl/sysdeps/unix/sysv/linux/raise.c: Bestand of map bestaat niet

"Bestand of map bestaat niet" means "File or folder does not exists". I'm sorry about that.
Comment 3 Florian Reisinger 2013-02-23 17:50:30 UTC
CAN'T confirm with Version 4.1.0.0.alpha0+ (Build ID: fd56eb98e63b4aac12c9633d5847a3fb964f326)
TinderBox: Win-x86@6, Branch:master, Time: 2013-02-22_21:43:36
Formatting is.... I am going to submit a bug for that...
Comment 4 Julien Nabet 2013-02-23 17:53:40 UTC
Created attachment 75416 [details]
bt + console logs on master

On pc Debian x86-64 with master sources updated today, I reproduced the crash.

I attached console logs + bt
Comment 5 Julien Nabet 2013-02-23 17:55:26 UTC
Cédric/Michael: one for you?

(bt attached with master sources updated until commit c4cc63badc506a00ee92e588d47e4f93e22fe1b5)
Comment 6 Not Assigned 2013-02-28 13:10:46 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

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

fdo#61309: writerfilter: filter out enormous numbering levels



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 7 Michael Stahl (CIB) 2013-02-28 13:24:18 UTC
the document contains a numbering level 12:

              <w:numPr>
                <w:ilvl w:val="12"/>
                <w:numId w:val="0"/>
              </w:numPr>

but Writer supports only numbering levels less than 10.

fixed on master, on older branches it's not an assert so no problem.