User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2486.0 Safari/537.36 Edge/13.10586 Build Identifier: LibreOffice 5.1.4.2 When trying to store a big file (book manuscript, 452pp) writer crashes with bad allocation error. In former versions this appeared often (>50%), now it is 100%. Maybe due to version maybe due to slightly increased file. ODT-File will be submitted if this seems to be helpful. Reproducible: Always Steps to Reproduce: 1.Load file 2.Store file (save, save as) 3. Actual Results: bad allocation message box Expected Results: storing the file [Information automatically included from LibreOffice] Locale: de Module: TextDocument [Information guessed from browser] OS: Windows 10 OS is 64bit: yes Reset User Profile?Yes
Error not present in 5.2.0.1. but in 5.3.0.0. and 5.1.4.2.
(In reply to Wilfried Koch from comment #1) > Error not present in 5.2.0.1. but in 5.3.0.0. and 5.1.4.2. And were all these versions 64-bit or were some 32-bit? Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
I am not quite sure. But in general I install 64 bit versions. I can make you the file available. It has been growing over the years with different versions of Openoffice and LibreOffice. So I think ist could contain some special structures. The file is the manuscript of a recently published book. I expect your to youse it for debugging purposes only and not to publish it in the net.
(In reply to Wilfried Koch from comment #3) > I am not quite sure. But in general I install 64 bit versions. > I can make you the file available. It has been growing over the years with > different versions of Openoffice and LibreOffice. So I think ist could > contain some special structures. > The file is the manuscript of a recently published book. I expect your to > youse it for debugging purposes only and not to publish it in the net. It will be publicly available, if you attach it. And if you don't attach it, developers will be unable to test with it. You could install an older version where the problem is not 100% and anonymize the content: https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission#Sanitize_file_text Then verify with the anonymized document that it crashes in LibreOffice 5.1.4 100% of the time. You can use this program to quickly download and install old versions: https://wiki.documentfoundation.org/SI-GUI
What about sanitizing pictures? can a 80MB file be uploaded in the bug management system or do I have to chose another way?
(In reply to Wilfried Koch from comment #5) > What about sanitizing pictures? > > can a 80MB file be uploaded in the bug management system or do I have to > chose another way? Ah :) Yeah it gets a bit tricky with pictures. One useful thing you could do is try to get a backtrace of the crash: https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg
Created attachment 126279 [details] ErrorMessage in Parallele Install Trying parallel installation ends (crashes) with the error message shown n teh picture: "This installation package could not be opened. Ask the manufacturer to check if it is a valid windows installation package." After the crash a message similar to "SI changed bootstrap.ini automatically" pops up. Pressing edit bootstrp.ini showed a directory with no bootstrap.ini in it. I tried 5.1.03 /64 alone . There was no error with the sanitized file. I will surely do more tests but only if parallel installation is possible. Everything else i too time consuming.
Aha, that is unfortunate. But why did you try 5.1.3.1 and not 5.1.3.2 aka the release?
I installed 5.1.3.2.(32) It shows problems with the sanitized file. "bad allocation" error about every 2nd time. The size of this file is nearly 50 MB. So I cannot send it here. For a realistic test I think you need such a big file. Can I send it to you using dropbox?
(In reply to Wilfried Koch from comment #9) > I installed 5.1.3.2.(32) It shows problems with the sanitized file. "bad > allocation" error about every 2nd time. The size of this file is nearly 50 > MB. So I cannot send it here. For a realistic test I think you need such a > big file. Can I send it to you using dropbox? If you can share it publicly, just tell us the Dropbox link in a comment.
Dropbox link mailed to Buovjaga
(In reply to Wilfried Koch from comment #11) > Dropbox link mailed to Buovjaga So do you give permission to share this link in public?
(In reply to Buovjaga from comment #12) > (In reply to Wilfried Koch from comment #11) > > Dropbox link mailed to Buovjaga > > So do you give permission to share this link in public? I get this: "Wilfried Koch wants to share the file ...odt with you. Join Dropbox to view this file" I'm not joining Dropbox.. Please share it with a public link.
https://www.dropbox.com/s/vcz8v96mnaz85yt/LazBuch_1_20160716_1548_SANI.odt?dl=0
Cannot reproduce on osx. LO stored the file as expected. Guess windows only is correct then. Version: 5.3.0.0.alpha0+ Build ID: e6c004dd9f24c32f5e7468182a5e8d42293ec7b6 CPU Threads: 4; OS Version: Mac OS X 10.11.6; UI Render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2016-06-17_06:40:25 Locale: de-DE (de.UTF-8)
No problem here either. Tried saving 4 times for each version. Wilfried: how much memory do you have in your computer? Win 7 Pro 64-bit, Version: 5.1.3.2 (x64) Build ID: 644e4637d1d8544fd9f56425bd6cec110e49301b CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Locale: fi-FI (fi_FI) Version: 5.3.0.0.alpha0+ Build ID: 62442d9066ea553a4b68b8a93fa54748cbe96e06 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-07-19_00:20:50 Locale: fi-FI (fi_FI); Calc: CL
Windows 10 8GB working storage Last experiences with 5.1.3.2 32 Bit
(In reply to Wilfried Koch from comment #17) > Windows 10 > 8GB working storage > Last experiences with 5.1.3.2 32 Bit I have the same amount of memory on my Windows laptop. My 5.1.3 was 64-bit, but 5.3 was 32-bit, so it is strange that I did not see the problem. It does sounds like running out of memory.
I just run the test again and had a look on the task manager on the second screen. Before start: CPU load 1,5% used working storage 580 MB libreoffice running, file loaded CPU load 0,5% used working storage 720 MB after 1st storing (seeming OK fromplain user's view) CPU load 0,5% used working storage 1330 MB 2nd storing crashes This looks for me like a memory leak
(In reply to Wilfried Koch from comment #19) > I just run the test again and had a look on the task manager on the second > screen. > > Before start: > CPU load 1,5% used working storage 580 MB > libreoffice running, file loaded > CPU load 0,5% used working storage 720 MB > after 1st storing (seeming OK fromplain user's view) > CPU load 0,5% used working storage 1330 MB > 2nd storing crashes > > This looks for me like a memory leak If you are feeling like doing some science, here are instructions for getting information on the leak: https://wiki.documentfoundation.org/Development/How_to_debug#Searching_for_a_memory_corruption_on_Windows_using_DrMemory
No repro with: Version: 5.4.0.0.alpha0+ Build ID: d0288a482a3dc0f50f535565e4c66a95bb140942 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-12-26_23:25:18 Locale: nl-NL (nl_NL); Calc: CL
Tried the file on Windows XP, no problems here, too. Did loading, changing some characters, saving, saving as odt and docx, all of this several times. Version: 5.3.2.2 Build-ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1 CPU-Threads: 4; BS-Version: Windows 5.1; UI-Render: Standard; Layout-Engine: neu; Gebietsschema: de-DE (de_DE); Calc: group As nobody could reproduce the bug until now, closing this as WORKSFORME. Wilfried, if you still see the bad behaviour, please reopen the bug.