LibreOffice Writer 220.127.116.11 is unable to open a text file .odt . LibreOffice does not respond. I can do nothing.
Thank you for filing the bug. Please send us a sample document, as this makes it easier for us to verify the bug.
I have set the bug's status to 'NEEDINFO', so please do change it back to 'UNCONFIRMED' once you have attached a document.
(Please note that the attachment will be public, remove any sensitive information before attaching it.)
How can I eliminate confidential data from a sample document?
Created attachment 143959 [details]
The attachment is my book project in arabic.
EXPLANATION OF MY PROBLEM:
Hello. Thank you for your interest in my problem.
It was difficult for me to send Bugzilla my LibreOffice ".odt" document. Because this document blocks the software "OpenOffice 4.1.5", or "LibreOffice 6.0.1".
BEFORE, I had written my document (which is a book project) under "Microsoft Office Word 2013", under Windows Vista, on an old Dell PC. Then, I had to work my document under "Microsoft Office Word 365", under Windows 10, on my new Asus PC. This book project consisted of more than 200 pages. Until then, everything worked very well.
AFTER, has arrived the expiration of the 30-day trial period of "Microsoft Office 365". So I tried to work under "OpenOffice Writer 4.1.5". I transformed my document from "docx" format to "odt". But when I try to open my document, the program "OpenOffice Writer 4.1.5" hangs, and I can not do anything. I also tried "LibreOffice 6.0.5", then "LIbreOffice 6.1", then "WPS". But all these programs can not even open my document, and they lock up quickly, and then they close abruptly.
To open my paper when, I click on the "name" of my document, and then on the "OPEN" icon. The "OpenOffice 4.1.5" program, or "LibreOffice 6.1", crashes, and does not respond to any command. And I can not do anything. It takes 7 minutes for my document to open. Or this program closes completely and brutally.
My document, on which I work, is a bit special. It's a draft book written in Arabic. (Almost all words are Arabic fonts, such as "XB Roya", and a few words are in Latin fonts, such as "Times New Roman").
This document includes: margins, a binder, titles (4 levels), with frames, and background, sub-titles, formatted styles, paragraph styles, a foot-of-page, notes-of-down-of-page, page numbers, table of contents (hypertext links), etc.
IMPORTANT NOTE: My document, the same document "odt", on my old Dell PC, and under Windows Vista, and under "OpenOffice 4.1.5", it works excellently. But this same document "odt", on my new PC Asus, under Windows 10, under "OpenOffice 4.1.5", hangs, and closes abruptly.
Assumption : The problem probably comes from the Windows system. Or more exactly, the problem comes from the relationship between the Windows system and the "OpenOffice" program.
NOTE: The document I am sending you (as an attachment) is not the complete document, but only part (about 40 pages on 250 pages, without the table of contents). I have also replaced some characters by others (to avoid the dissemination of personal information). Unfortunately, this partial document can probably contain fewer problems (bugs) than the original document.
With the expression of my feelings of greetings, and gratitude, respect, and consideration, for all those who contribute to the development of Open Source products.
it crashes in
Id. de compilación: b3972dcf1284967612d5ee04fea9d15bcf0cc106
Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.;
Configuración regional: es-ES (es_ES); Calc: group threaded
but not in
ID de la construcció: 1:6.0.6~rc1-0ubuntu0.16.04.1
Fils de CPU: 4; SO: Linux 4.15; Renderitzador de la IU: per defecte; VCL: gtk3;
Configuració local: ca-ES (ca_ES.UTF-8); Calc: group
so, WIN only...
I can also reproduce it in
Id. de compilación: de093506bcdc5fafd9023ee680b8c60e3e0645d7
Configuración regional: es_ES
but not in
No crash here Win 7 with 6.2+, just slow fileopen with dump.
5508c938 8b430c mov eax,dword ptr [ebx+0Ch]
Same with 4.4 and 4.0, no crash but dump. 3.6 dump and crash. OO has no dump.
So I'm not sure how bibisect can help.
34 secs on Win 6.2
49 secs on Win 4.3.0
4 secs on Win 3.5.0
20 secs on Linux 6.2
3 secs on Linux 3.6.7
Will look at bibisecting on Linux.
Version: 18.104.22.168.alpha0+ (x64)
Build ID: 3208fcb3a36d75d6290d9c548430682f153b09db
CPU threads: 4; OS: Windows 10.0; UI render: default;
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-09-20_22:43:20
Locale: fi-FI (fi_FI); Calc: threaded
Arch Linux 64-bit
Build ID: 0ffa7a733d834647dfd59b864c52a015028822b6
CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5;
Locale: fi-FI (fi_FI.UTF-8); Calc: threaded
Built on September 21st 2018
Created attachment 145109 [details]
Callgrind output from master
It is still very quick to open in the last commit of Linux 50max bibisect repo (I don't have newer ones)
On current master, this takes 4.5s on my machine. Does not seem worth optimising further.
Indeed, it takes
Build ID: e74de110d16c95414fac7541c8fe6541d4597113
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Closing as RESOLVED WORKSFORME