Bug Hunting Session
Bug 102073 - TABLE with images in footnote and endnote hangs on FILEOPEN
Summary: TABLE with images in footnote and endnote hangs on FILEOPEN
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha1
Hardware: All All
: medium critical
Assignee: Michael Stahl (CIB)
URL:
Whiteboard: interoperability target:5.3.0 target:...
Keywords: bibisected, bisected, filter:docx, regression
: 102855 (view as bug list)
Depends on:
Blocks: Footnote-Endnote
  Show dependency treegraph
 
Reported: 2016-09-12 11:52 UTC by Milos Sramek
Modified: 2017-07-17 06:57 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
table with images in endnote and footnote (6.17 MB, application/zip)
2016-09-12 11:52 UTC, Milos Sramek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Milos Sramek 2016-09-12 11:52:40 UTC
Created attachment 127274 [details]
table with images in endnote and footnote

Hi,

LO hangs on fileopen if there is a table with images in a footnote or endnote (See the attached files File_1280-fail.docx  File_1331-fail.docx)
It opens correctly only if the table is small (2x1). In that case the table is loaded correctly (see the attached file File_1331-OK.docx)

It hangs the LO online version too.

regression bibisected using the lo-linux-dbgutil-daily-till51 repository. Earlier versions do not hang, the table is however not loaded correctly. Thus, maybe that the problem is related to the attempt to correct loading of tables with images.

--
Milos

Bibisection log (the same for both endnote and footnote):

5d4034b38112a1ff0c69df30ab28d19394872b0e is the first bad commit
commit 5d4034b38112a1ff0c69df30ab28d19394872b0e
Author: Miklos Vajna <vmiklos@collabora.co.uk>
Date:   Sat Nov 14 04:44:57 2015 +0100

    2015-11-14: source-hash-3a906cedeb700ffb950b46e728b20676956cec72

:100644 100644 c74de43ddf156bb12824bdfce5b953e34a645a35 66e5c37a6614722d2351fc7f372daf802a5bbd67 M	build-info.txt
:040000 040000 a948ca8705751c4b8f59e73799d01b77bf809e75 8ec89cfaf5ecfa0c775b70de2b2e7aed84a4e6b0 M	opt
milos@trigan:~/LO/lo-linux-dbgutil-daily-till51$ git bisect log
# bad: [ea0f3871e9b080744fc700c21e876d0ba9c663d5] 2015-11-25: source-hash-7289a140fc68dc898ba2b2357cc960968195f236
# good: [2b392af9c8f54629e3a3a98a8c92fa5af1c6722f] 2015-05-20: source-hash-90e2dabb8d0bb5382234be776c2ad0e2d5d9e224
git bisect start 'master' 'oldest'
# good: [a8d19eafb9e195a85359dd8cdc5c46c38295caa0] 2015-08-22: source-hash-79fb61efb847405fa47235002b52ee8efad5e339
git bisect good a8d19eafb9e195a85359dd8cdc5c46c38295caa0
# good: [2ad98b12d82c4ada5756881f0d6074154976e95c] 2015-10-08: source-hash-2e6feddc53830406fa04b4a0aea49bb8438dc702
git bisect good 2ad98b12d82c4ada5756881f0d6074154976e95c
# good: [e4287d7f4aebf2543103c3dde6e1463edb50b8c2] 2015-11-01: source-hash-bf4c2f74de6b82177b5f047a96b7f8e0d54a9459
git bisect good e4287d7f4aebf2543103c3dde6e1463edb50b8c2
# good: [455dfd0b0d56d73db59d588c1cd433206f275974] 2015-11-13: source-hash-41379970e8c6b75563b7c162b4e760b9e93a5bea
git bisect good 455dfd0b0d56d73db59d588c1cd433206f275974
# bad: [db3a80c5b2639cdb978d9679299e5f2833a28e59] 2015-11-19: source-hash-db5358764fdb1855ee6b401d6165ed65677bdfbe
git bisect bad db3a80c5b2639cdb978d9679299e5f2833a28e59
# bad: [e9d74d2859da3a5091b7d2bc4fd56d8b27285892] 2015-11-16: source-hash-1ba6f9ca615f55de30547612d67988218a983318
git bisect bad e9d74d2859da3a5091b7d2bc4fd56d8b27285892
# bad: [203db3210936bbe78a37ec5b26e55c63f0681cbd] 2015-11-15: source-hash-7272e8df62a12d6172b297d7a82a0265cd1bc44a
git bisect bad 203db3210936bbe78a37ec5b26e55c63f0681cbd
# bad: [5d4034b38112a1ff0c69df30ab28d19394872b0e] 2015-11-14: source-hash-3a906cedeb700ffb950b46e728b20676956cec72
git bisect bad 5d4034b38112a1ff0c69df30ab28d19394872b0e
# first bad commit: [5d4034b38112a1ff0c69df30ab28d19394872b0e] 2015-11-14: source-hash-3a906cedeb700ffb950b46e728b20676956cec72
Comment 1 Aron Budea 2016-09-12 18:21:36 UTC
Hi Milos, thank you very much for the report and the analysis.
Hang confirmed with v5.2.1.2 / Windows 7. Raising severity to critical.
Comment 2 Xisco Faulí 2016-09-12 21:21:23 UTC
Hi Oliver,
it looks like your commit f47bd0561cdf4c2b4fbe2c7e396533cf85408cb7 introduced this regression. Could you please take a look whenever you have some time?
Regards
Comment 3 Commit Notification 2016-09-21 13:37:04 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

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

Related: tdf#102073 survive table in footnotes edgecases

It will be available in 5.3.0.

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 4 Caolán McNamara 2016-09-21 13:37:17 UTC
I don't think the bisect helps much in this case to provide a solution, by which I mean that importing tables in footnotes from docx was enabled before this change, and they are fragile in the layout (you can't create them from the menus).

https://gerrit.libreoffice.org/#/c/29142/ is a possible route to make this not hang
Comment 5 Michael Stahl (CIB) 2016-09-28 12:53:07 UTC
(gdb) p rLine.m_pTextNode
$8 = (const SwTextNode *) 0x77d7120
(gdb) p rLine.m_pTextNode->GetNodes()
$7 = (SwNodes &) @0x4b52500: {
  <BigPtrArray> = BigPtrArray of length 72 = {
[   0] 0x4ec9b00            StartNode ,
[   1] 0x2faa650              EndNode ,
[   2] 0x4e5b5e0            StartNode ,
[   3]  0x79d6ce0           StartNode ,
[   4]   0x712f7a0           TextNode "\002 ",
[   5]   0x71422d0          TableNode ,
[   6]    0x70f5370         StartNode ,
[   7]     0x77d7150         TextNode "\001",
           ^^^ loop is here
[   8]    0x465f410           EndNode ,
[   9]    0x2908e50         StartNode ,
[  10]     0x4650680         TextNode "",
[  11]    0x4e86670           EndNode ,
[  12]    0x4e866b0         StartNode ,
[  13]     0x2f7c400         TextNode "\001",
[  14]    0x2bd4490           EndNode ,
[  15]    0x2bd44d0         StartNode ,
[  16]     0x4e85ca0         TextNode "",
[  17]    0x7156ef0           EndNode ,
[  18]    0x7156f30         StartNode ,
[  19]     0x4674060         TextNode "\001",
[  20]    0x710fcd0           EndNode ,
[  21]    0x31ba900         StartNode ,
[  22]     0x6c30570         TextNode "",
[  23]    0x797b400           EndNode ,
[  24]    0x4d74260         StartNode ,
[  25]     0x46744b0         TextNode "\001",
[  26]    0x4d742b0           EndNode ,
[  27]    0x4d44b50         StartNode ,
[  28]     0x2ff42e0         TextNode "",
[  29]    0x4d44ba0           EndNode ,
[  30]    0x4d5b210         StartNode ,

it loops by creating a line with only a SwFootnoteNumPortion, but
the node inside the table shouldn't have a footnote number in the
first place because node #4 is the first node in the footnote.
Comment 6 Michael Stahl (CIB) 2016-09-28 13:54:34 UTC
fixed on master
Comment 7 Commit Notification 2016-09-28 13:55:53 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

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

tdf#102073: sw: do not create SwFootnoteNumPortion inside table

It will be available in 5.3.0.

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 8 Commit Notification 2016-09-29 20:49:34 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cda5c1f15f73922026992036bdaf631bad19c76f&h=libreoffice-5-2

tdf#102073: sw: do not create SwFootnoteNumPortion inside table

It will be available in 5.2.3.

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 9 Milos Sramek 2016-09-30 05:06:18 UTC
It works now, verified using master
Thanks!
Milos
Comment 10 Caolán McNamara 2016-09-30 12:14:54 UTC
*** Bug 102855 has been marked as a duplicate of this bug. ***