Oh, thank you and chr.hoe for confirming this. The thing is it’s not easy to identify the source, esp when LO doesn’t freeze/crash immediately. Now I believe many more are facing this issue, not knowing why. They’re probably blaming LO!
Since Dnaber hasn’t faced the issue, I suspect it’s OS-related. I’m using Win7 HP 64-bit. What about you two?
Dnaber, please consider this a critical regression bug. I’m still having my LT2.9 disabled.
Now I’m considering keeping the new en\grammar.xml, install LT2.8, and replace the file. Hope that works.
I’m also using Win7 SP1 64bit but the Pro version - but that’s possibly unimportant.
I agree with you Kumara - this issue should be considered a critical regression bug and in addition should be communicated officially as it is difficult to identify LT as the problem source … I first blamed LO for being that unstable, too!
Kumara, please let us know if your experiment with LT 2.8 worked for you - if so, I would do the same.
chr.hoe [via LanguageTool User Forum] wrote thus at 03:44 PM 04-05-15:
Kumara, please let us know if your experiment with LT 2.8 worked for
you - if so, I would do the same.
Haha! Idea is good, but doesn’t work. Now I’m back to plain LT2.8.
Hope this get fixed soon. I’d be willing to install the nightly build
to test when that’s done.
After doing some dummy-editing I tryed to open the About dialog again but it won’t show up. A few moments later I’ve got the well known “osl::create failed” and LO crashed. Sorry, but I’m not able to get a second value for the memory sizes as either the dialog doesn’t show up or LO crashes before I can check.
Second attempt: I started with an empty document and noticed after opening the About dialog several times that the amount of free memory is oscillating - it’s going up and down from 15MB to 5MB. Now I’ve loaded the questionable document which usually crashes LO and did the same: opened the About dialog of LT several time without doing something else - and again: the free memory is oscillating between 20MB down to 2MB (the lowest figure I saw). As we are taking only samples of the changing amount of free memory it is pretty easy to imagine that it gets close to zero somewhere in between and if really touches zero at such a point that this causes the crash. But this is only a guess as the few samples of the memory changes I get by using the About dialog are by fare not sufficient to really follow the changes and to tell what really happens. By the way the “total” memory is only 40MB this time instead of 126MB at the first attempt. I wonder how this is possible?!?
Starting LO with an empty document and checking About dialog - oh, ups, no memory sizes. ;-(
Loading the questionable document and doing some dummy edits - no crash!
Checking another huge document I’ve to work with and again - no crash no matter what I’m doing! Seems that this version (LanguageTool-2b84b9f0e1194a835492fdc6ac016241b24152cb-2015-02-20.oxt) doesn’t have the bug which is causing the crash! I guess I will keep this version until a new release with a fix is available officially!
I hope that I’ve tested everything you wanted to be tested - if not just let me know.
Thanks for running the tests. The bad new is that the version that works for you is some version between 2.8 and 2.9 and we’ll need more tests to see where exactly the issue got introduced.
The memory values are values internal to Java, it’s normal that values are oscillating. How much memory does your computer have and which version of Java are you using?
My computer is a DELL M6600 with 16GB physical RAM - so there should be plenty of space left.
The Jave version I’m using currently is the most recent 1.8.0_45 but with “LT 2.9 release” I’ve tried 1.7.0_80 also with no difference - it still crashed.
I will test the two new versions shortly and get back to you.
Okay, the problem is that Java doesn’t get enough memory for some reason. Could you try this?
Go to Tools -> Options -> Advanced. Select the JVM currently active (there might be more than one) and click “Parameters…” Of the existing parameters (if any), is there one that starts with “-Xmx”? If so, what does it look like? If not, could you add a parameter “-Xmx900M”, make sure to click “Assign” and restart LO. This should fix the problem. Obviously this test should be done with a version of LT that currently still crashes for you.
I’ve tried both LT versions with a PC operated under Windows 7 SP1 64bit (8GB memory), java1.7.0_51 and LibreOffice 4.3.6.2.
My PC works fine with LanguageTool-5fb1424dad593096193d58933bc504e3cdd9d155-2015-03-15.oxt, but not with LanguageTool-99cd52c01e1ee1eef9b034dbfd5109bcf7a79129-2015-02-28.oxt.
With the latter, like with LT 2.9, when opening a file, LibreOffice hangs.
NB
This PC is different from the PC that renders the error “osl::create failed”.
I have some interesting news although I haven’t tried the two last versions until now:
The version which I reported to work before (LanguageTool-2b84b9f0e1194a835492fdc6ac016241b24152cb-2015-02-20.oxt) crashes after 30min… 1h with LO just sitting in the background and a huge document open. Same error: “osl::create failed”. I just verified - this doesn’t happen with LT 2.8 release.
Yes, I’ve a 32bit version of Java installed as it is the only version LO works with as a 32bit application! I just tried and installed a 64bit version of java 1.8.0_45 in parallel but if it is selected in LO it reports a defective JRE on startup.
If I add the command line parameter you asked for to the 32bit JRE I get the “JRE defect” error on startup as well. Obviously I couldn’t test if this fixes the “osl::create failed” error for that reason.
I hope to have time to test the other two versions this evening.
I do not know exactly how the error comes up. When opening a document or editing one, it appears. But concerning the first case, a document that always rendered the error was identified. So I used it for the test.
Unfortunately, because it contains personal data, I cannot upload it or send it to you. But it is written in French and another language which is not targeted by LT.
Apart from French, I use certain languages including English (US, UK), Spanish (Spain) and some others, not necessarily for writing a text but citations, etc.
Very recently, I have updated LibreOffice to 4.4.3.2 and no longer receives that error, with LT 2.9 installed, when opening the file in question.
Until 4.4.3.1 with LT 2.9, I always received the error or LibreOffice hung when opening the file.
But I am not sure if the problem has completely been resolved. I will continue using LibreOffice 4.4.3.2 and LT 2.9, and if there is a problem, I will report it here.
@dnaber: Yes, I’ve added the option as a seperate item but it didn’t work. If I do so LO is complaining that the selected JRE is defect.
Regarding languages, I use two different documents for testing. One is a mixture of mainly German with parts of Polish and English and the second is English-only but is quite a huge document (~200 pages).
LT 2.8 works perfectly with both documents whereas LT 2.9 and all test versions fail in one or the other way.
-Java inside LO gets started with the default memory settings.
-On 32 bit machines or with 32 bit Java, this means Java gets 256MB of memory. Minus some overhead, this is what you see as 247MB in the About dialog (you could try to confirm that by running “java -XX:+PrintFlagsFinal -version” and look for “MaxHeapSize”).
-LT grows a bit with each release, as we add new error detection rules.
-There was no specific change between 2.8 and 2.9, just the usual growth.
-With 2.9 you reached the limit of 256MB for your documents (size and number of languages matter).
Solutions:
-Make the “-Xmx” option work to give Java more memory
-Use the 64bit version of LO and Java (maybe only available as development version, see 61683 – 64-bit version of LibreOffice on Windows)
-Optimizing memory usage in LT would be nice but only moves the problem to the future
I can confirm the 256MB default heap limit in 32bit java and I was able to use the -Xmx option to change this value on the command line but when I put the same option in the parameter dialog of LO it always complain that the JRE is broken - I don’t know why!
The screen shot of the JRE dialog is attached.
64bit LO on Windows is not really an option at the moment as the development is not very advanced and stable currently. It will be the solution in the future for sure - in that way optimizing LT memory usage could provide just the required time for waiting for the 64bit version to stabilize…
:create failed” and LO crashed. Sorry, but I’m not able to get a second value for the memory sizes as either the dialog doesn’t show up or LO crashes before I can check.
:create failed”.
