Bug 135708 - .doc / .docx generate Page Loop on opening
Summary: .doc / .docx generate Page Loop on opening
Status: RESOLVED DUPLICATE of bug 38575
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Anchor-and-Text-Wrap
  Show dependency treegraph
 
Reported: 2020-08-13 12:27 UTC by Timo Henke
Modified: 2020-10-08 12:13 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
will crash libreoffice on open (125.50 KB, application/msword)
2020-08-13 12:28 UTC, Timo Henke
Details
Example file (no-looping) (115.45 KB, application/vnd.oasis.opendocument.text)
2020-08-13 14:42 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Timo Henke 2020-08-13 12:27:27 UTC
Description:
I have a a document that, when i open it with libreoffice (up to latest 7.x Version on windows and linux --headless) will force libreoffice to generate an endless amount of pages.

I will attach the document to reproduce the bug every time it is opened.

I tried to track the problem down to its core and i guess it is caused by the lines that are made using underscore "_" chars.

When i remove all the underscore lines, the document opens.

As we use libreoffice in headless mode on a web-service this is a major problem, because the service will hand without notice or error.

I / we need help ...

Steps to Reproduce:
1. Open the document

Actual Results:
Using Windows you see the page counter at bottom left increasing with no end. On Linux (headless) it just get stuck.

Expected Results:
application is stuck until OOM


Reproducible: Always


User Profile Reset: No



Additional Info:
open the file or error out
Comment 1 Timo Henke 2020-08-13 12:28:11 UTC
Created attachment 164253 [details]
will crash libreoffice on open
Comment 2 Xisco Faulí 2020-08-13 13:38:12 UTC
Reproduced in

Version: 7.1.0.0.alpha0+
Build ID: df37937018fe8e87dad5dd97689632044ba56de3
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

The document only has 1 page
Comment 3 Xisco Faulí 2020-08-13 13:39:25 UTC
also reproduced in

Version: 5.2.0.0.alpha0+
Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.19; Render: default;
Comment 4 Xisco Faulí 2020-08-13 13:40:25 UTC
Also reproduced in

Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Comment 5 Xisco Faulí 2020-08-13 13:40:49 UTC
@Justin, I thought you might be interested in this issue
Comment 6 Telesto 2020-08-13 14:42:25 UTC
Created attachment 164267 [details]
Example file (no-looping)

1. Open the attached file (doesn't loop by default)
2. Right click the frame at the right
3. Anchor to paragraph/to character and looping starts
Comment 7 Telesto 2020-08-13 14:52:01 UTC
Format -> Page Style - Header tab -> Uncheck Same content on first page and looping goes away
Comment 8 Timo Henke 2020-08-14 07:08:45 UTC
this bug is not about changing styles to make it loop but to prevent the loop / death of application that runs forever and never quit with an error (except OOM).

Using LibreOffice with this flaw can lead any service in headless mode to get stuck while in a GUI driven environment you could possibly kill the task.

If i would use the libreoffice binary directly for each call i could trap it with a timeout (bad idea) and send a kill to that pid. But it is running as a service with

--headless --invisible --nocrashreport --nodefault --nologo --nofirststartwizard --norestore --accept=socket,host=127.0.0.1,port=2002,tcpNoDelay=1;urp;StarOffice.ComponentContext

as soon as the service will process the attached file it is stuck and blocks itself.
Comment 9 Timo Henke 2020-08-17 08:40:26 UTC
(In reply to Telesto from comment #6)
> Created attachment 164267 [details]
> Example file (no-looping)
> 
> 1. Open the attached file (doesn't loop by default)
> 2. Right click the frame at the right
> 3. Anchor to paragraph/to character and looping starts

very well analysed i guess - so it is a combination of content and format that will force the crash / loop / dead-end.
Comment 10 Timur 2020-10-08 09:54:38 UTC
Let's assume duplicate of existing major bug.

*** This bug has been marked as a duplicate of bug 38575 ***
Comment 11 Timo Henke 2020-10-08 10:52:03 UTC
(In reply to Timur from comment #10)
> Let's assume duplicate of existing major bug.
> 
> *** This bug has been marked as a duplicate of bug 38575 ***

you speak about the "libreoffice blocks" from 7 years ago?

So - if this is a dupe ... will it mean the authors of this application are unable to fix that bug within 7 years?

For me as a headless user, this is a very critical bug ... I for myself found a way to bypass it by watching the task (linux side) and kill it, if it is not finished within 30 seconds.

This is a very brute way and will not work for jobs taking longer than 30 seconds but for what i need it (convert document to pdf) - it will do the job.
Comment 12 Timur 2020-10-08 11:45:40 UTC
Timo, your comment is often seen butis also "no-value", it just servers to annoy people. 
Who do you complain to? To us, volunteers, who are givers? While you as a user are 'angry' taker? 
You want it to be fixed? Good, do it yourself, of find someone who will do it as a volunteer, or pay to programmer or company to have it done, or just wait, month or decade. 
I'l never understand people like you, who don't bother to understand how OSS project functions but complain instead, repelling others who contribute.
Comment 13 Timo Henke 2020-10-08 12:13:14 UTC
(In reply to Timur from comment #12)
> Timo, your comment is often seen butis also "no-value", it just servers to
> annoy people. 
> Who do you complain to? To us, volunteers, who are givers? While you as a
> user are 'angry' taker? 
> You want it to be fixed? Good, do it yourself, of find someone who will do
> it as a volunteer, or pay to programmer or company to have it done, or just
> wait, month or decade. 
> I'l never understand people like you, who don't bother to understand how OSS
> project functions but complain instead, repelling others who contribute.

I know how open source works and at no point have I discredited the "givers".

Maybe it is because i am not writing in my native language here and therefore use words or phrases that attack you or someone else. I'm sorry for that.

As said, for me this is a critical bug, not just a cosmetics or the like. If a bug is known for like 7-9 years and will / can harm a normal user in a normal daily situation, would'nt it get some kind of "priority" to fix it? That is what i wanted to say with my short feedback.

I did my best in reporting and am again sorry when someone feels attacked.