Bug 47935 - EDITING: Crash when inserting objects into a table
Summary: EDITING: Crash when inserting objects into a table
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.1 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-27 00:36 UTC by bobbug
Modified: 2015-04-25 19:27 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
A document making libreoffice crash (122.23 KB, application/vnd.oasis.opendocument.text)
2012-03-27 00:36 UTC, bobbug
Details
Bug 47935 - WinDbg session (37.66 KB, text/plain)
2012-06-04 03:24 UTC, bfoman (inactive)
Details
bt on 3.5 (7.17 KB, text/plain)
2012-10-27 11:37 UTC, Julien Nabet
Details
here the same problem under windows with procdump backtrace (14.21 KB, text/plain)
2014-07-04 10:40 UTC, Hkais
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bobbug 2012-03-27 00:36:21 UTC
Created attachment 59104 [details]
A document making libreoffice crash

Problem description: When copy/pasting certain kind of content into a table, LibreOffice crashes. Additionally, some kinds of documents make LibreOffice crash.

Steps to reproduce:
1. Open the document in the attachment (sorry, it is in german, but the content is unnecessary)
2. Experience LibreOffice crashing (after some time, e.g. when scrolling)

1. Open the document http://billhome.at/test.odt
2. Go to the end of the document
3. Insert a new table (I had one without borders)
4. Copy the graphics & text of "Java-Applet. Du musst dafür im Computerraum sein" into the table (e.g. using drag & drop)

Current behavior: OpenOffice crashes

Expected behavior: OpenOffice doesn't crash.

Platform (if different from the browser): Windows XP, 32bitt
              
Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
Comment 1 bfoman (inactive) 2012-06-04 03:24:28 UTC
Created attachment 62494 [details]
Bug 47935 - WinDbg session

Confirmed with:
LO 3.5.4.2 
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit

Crash with attachment 59104 [details].

Attached full WinDbg session.
Comment 2 bfoman (inactive) 2012-06-19 07:51:44 UTC
NEW as bug confirmed and bt attached.
Comment 3 Julien Nabet 2012-10-27 11:28:38 UTC
On pc Debian x86-64 with master sources updated today and a brand new LO profile, I don't reproduce the problem.
Comment 4 Julien Nabet 2012-10-27 11:30:12 UTC
On pc Debian x86-64 with 3.6 updated today and a brand new LO profile, I don't reproduce the crash but have these kinds of logs:
warn:legacy.osl:5707:1:/home/julien/compile-libreoffice/libo_3_6/sw/source/core/layout/anchoredobject.cxx:668: <SwAnchoredObject::GetObjRectWithSpaces> - cache for object rectangle inclusive spaces marked as valid, but it couldn't be. Missing invalidation of cache. Please inform OD.
warn:legacy.osl:5707:1:/home/julien/compile-libreoffice/libo_3_6/sw/source/core/layout/flylay.cxx:1033: !pClipFrm: if you can reproduce this please file a bug
warn:legacy.osl:5707:1:/home/julien/compile-libreoffice/libo_3_6/sw/source/core/layout/objectformattertxtfrm.cxx:233: <SwObjectFormatterTxtFrm::DoFormatObj(..)> - anchor frame not marked to move forward
Comment 5 Julien Nabet 2012-10-27 11:37:10 UTC
Created attachment 69147 [details]
bt on 3.5

On pc Debian x86-64 with 3.5 sources updated today and a brand new LO profile, I reproduced the crash.
Attached the bt with symbols.
Comment 6 Julien Nabet 2012-10-27 11:40:00 UTC
Cedric: Should 3.5 branch be fixed or there won't be 3.5.8? What do you think about logs of 3.6?
Comment 7 Cédric Bosdonnat 2014-01-20 08:57:33 UTC
Restricted my LibreOffice hacking area
Comment 8 Hkais 2014-07-04 10:40:01 UTC
Created attachment 102263 [details]
here the same problem under windows with procdump backtrace
Comment 9 Gordo 2015-04-25 19:27:28 UTC
Could not reproduce.

Windows Vista 64
Version: 4.4.2.2
Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6

Changed to RESOLVED WORKSFORME.