Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash introduced in LT Plugin 6.3.1 #10282

Open
ColeBantam opened this issue Feb 6, 2024 · 20 comments
Open

Crash introduced in LT Plugin 6.3.1 #10282

ColeBantam opened this issue Feb 6, 2024 · 20 comments
Labels
office-integration the LibreOffice/OpenOffice add-on

Comments

@ColeBantam
Copy link

Hello there.

Plugin Version 6.3.1 crashes LibreOffice 7.6. LT 6.3.0 is working fine.

I attach two test-documents that reproducible trigger the crash on my system (Libo7.6.4, Win10, 64Bit, Azul Java 11.0.21).

Claus

LangTool_6.3.1_CrashExample.odt
LangTool_6.3.1_CrashExample.ods

@Luisa-LT Luisa-LT added the office-integration the LibreOffice/OpenOffice add-on label Feb 7, 2024
@FredKruse
Copy link
Contributor

@ColeBantam
I'm sorry, but I can't reproduce the bug. I tested with LO 7.6.4, LT 6.3.1 on Windows 10. How did the error appear? I was able to open both documents, and they were analyzed completely and correctly as far as I can tell.
Can you describe what exactly happened and when?

@ColeBantam
Copy link
Author

Ok, that took a while :D

I assume the reason why you can't reproduce the bug lies within the user-wordbook. Since some generations of LibreOffice you can add something in the field "Grammatik nach:" (grammar after[?]). I do have one entry there:

user_wordbook_screenshot

There has to be at least one of those entries in the user-wordbook. To add/edit this entry, you have to disable LanguageTool, otherwise LibO crashes immediately. Instead of manually adding that entry, you can use my standard.dic that I attached.

standard.dic.zip

FredKruse added a commit that referenced this issue Feb 14, 2024
@FredKruse
Copy link
Contributor

@ColeBantam
The bug should be solved. Please test the developer version (6.4-snapshot) tomorrow and give me feedback.

@ColeBantam
Copy link
Author

Seems like Snapshot-Server is failing? No new snapshots since two days ...

@ColeBantam
Copy link
Author

Snapshot builds are generated again :)

I can confirm, that "LanguageTool 6.4-SNAPSHOT (2024-02-15 18:55:06 +0100, 04b1f5e)" fixes the crash-bug 👍

Regards, Claus

@ColeBantam
Copy link
Author

Was happy too soon ...

Not the same crash, but there is another regression crash compared to 6.3.0:

crash_snaphot

Went back to 6.3.0 in my production-system.

@FredKruse
Copy link
Contributor

Could you please send me the following information:

  • How much memory does the computer have that crashed?
  • How much heap space is displayed in the log file (at LaguageTool/About - right button on top).
  • Did the crash happen with the document that you had already sent (otherwise, please send the document)?
  • Did you use the dic-file you sent (otherwise, please send the file)?

We should try to fix the bug before releasing production version 6.4.

@ColeBantam
Copy link
Author

I thought having the stackrace is enough ... There are two Problems:

1.) I can't give you the writer-file that caused the crash, because it contains customer-data.
2.) Even if I would give you the file, the crash isn't reproducible. I tried several times now.

If I open the file, that caused the crash last time, in my production installation with the Snaphot-Plugin, the toolbars become reproducible black, but its not crashing yet. In the test-installation (Same Windows-Installation, just a paralell LibO-Installation) there isn't even the black toolbars. Update: the black toolbars happen even at opening an empty writer window in my production-installation. With LT 6.3.0, there are no GUI problems at document open.

For the other points:

How much memory does the computer have that crashed?
-> 64GB. BUT, Java-Heap-Space is limited in LibO to 512MB (-Xmx512M) because LibO gets sluggish with huge heap-sizes (see other old bugs of me).

How much heap space is displayed in the log file (at LaguageTool/About - right button on top).
-> OS: Windows 10 10.0 (amd64)
-> LibreOffice 7.6.4.1 (The Document Foundation), de
-> Java version: 11.0.21 (Azul Systems, Inc.)
-> Java max/total/free memory: 512MB, 512MB, 285MB

Did the crash happen with the document that you had already sent (otherwise, please send the document)?
-> No, the crash did happen with another document.

Did you use the dic-file you sent (otherwise, please send the file)?
-> The Dic-File I sent last time was reduced to contain only the entry that was necessary to reproduce the bug. Now I removed private data from all DIC's in use and attached a zip of my wordbook-folder. Its not 1:1 the files I had in use during the crash, but its very close.
wordbook.zip

Hope that helps to narrow the problem down ...

@FredKruse
Copy link
Contributor

I think I've found the problem. The LT Extension works with different caches. Therefore, a maximum heap space of 512M is too small for documents like the test document you sent. I tested it and strongly recommend at least 1024M.
Now, I have built in mechanisms that roll back the advanced features when heap space runs out. But this takes away some features that give the extension an advantage over the built-in remote solution.
You can test it tomorrow.

@ColeBantam
Copy link
Author

ColeBantam commented Feb 20, 2024

Since the stracktrace clearly indicates that its an "out of memory"-error, it might help to shut down advanced functions when memory gets too low. But its funny, because the document that triggered that error is not big. Its wayyyyy smaller then the testfiles I have uploaded.
Testfile ODT: about 60.00 words
File that caused the above crash: about 2.300 words

It also doesn't explain the problem with the black toolbars at writer-startup with the snapshot version installed. Its extremely unlikely that writer needs more then 512MB heapsize for an empty document :D

But I'll test the new snapshot tomorrow of course :)

@ColeBantam
Copy link
Author

ColeBantam commented Feb 21, 2024

The current snapshot still has lots off issues ...

LT_Snapshot_Next-crash

This happened without any clicks in the actual document, I was still trying to get infos about the black-gui issue ...
Btw, heres a pic of what it looks like when I startup writer with the current LT-Snapshot-Plugin installed:

LT_Snapshot_BlackGui

Also, the new separate LT-Toolbar is really annoying. It always comes up right from the sidebar. If I disable it in view-menu, it comes back the next time. I really would like to disable the toolbar completely and put the necessary buttons to another toolbar instead, like it was in previous LT-Versions I guess? The new toolbar seems to be the main culprit for all the gui-issues.
If I have the black gui issue, it usually is enough to disable the LT-Toolbar and the gui turns normal immediately.

@FredKruse
Copy link
Contributor

OK, these are three different problems:

  1. There is not enough heap space (@danielnaber: or do you have another idea? LT fails when the internal LT spell checker is called). I can only get around this by doing a basic query and automatically switching to a simpler mode (paragraph mode) if the heap space is lower than 1024M. I'll install that.
  2. Not updating the LibreOffice interface correctly after the grammar checker starts: This is a problem that only occurs on Windows. I think this is not an LT issue but a LibreOffice issue. It would be nice if you reported it to the LibreOffice developer community.
  3. The dynamic toolbar is a separate issue. You can move it (right click, unfreeze and move it by mouse to where you want it). After a restart, it will open again in the location where you moved it, unless you have reinstalled LT. There is actually a problem if you deactivate it. This is a separate issue. Could you open a new issue for this? I'll take care of it.

@danielnaber
Copy link
Member

@danielnaber: or do you have another idea?

Not really, we usually optimize for server performance and not for memory use.

@FredKruse
Copy link
Contributor

3. The dynamic toolbar is a separate issue. You can move it (right click, unfreeze and move it by mouse to where you want it). After a restart, it will open again in the location where you moved it, unless you have reinstalled LT. There is actually a problem if you deactivate it. This is a separate issue. Could you open a new issue for this? I'll take care of it.

For this problem, I opened the following issue: #10348

I will continue to pursue the problem with the heap space in this issue

FredKruse added a commit that referenced this issue Feb 26, 2024
FredKruse added a commit that referenced this issue Feb 26, 2024
@FredKruse
Copy link
Contributor

  • The 3rd point has been solved, see issue.
  • The first point has now been solved in such a way that if there is not enough heap space, a warning is issued and only the LT spell checker is switched off. Meanwhile, the grammar check continues without restrictions. The LT spell checker can now also be turned on and off in the LT option panel.

Please test both points and provide feedback.

@ColeBantam
Copy link
Author

ColeBantam commented Feb 26, 2024

  1. There is not enough heap space (@danielnaber: or do you have another idea? LT fails when the internal LT spell checker is called). I can only get around this by doing a basic query and automatically switching to a simpler mode (paragraph mode) if the heap space is lower than 1024M. I'll install that.

Ahhh, Im ALWAYS on "paragraph mode" :D
But since 3.x versions, I'm not sure if paragraph mode is working as intended, because large documents still take ages to "process" (by LT) when opening. I'd expect that LT only tests the current paragraph in the document and not the whole document. Since it obviously scans the whole document in paragraph mode too, there might be no advantage in memory usage.

  1. Not updating the LibreOffice interface correctly after the grammar checker starts: This is a problem that only occurs on Windows. I think this is not an LT issue but a LibreOffice issue. It would be nice if you reported it to the LibreOffice developer community.

I could open a bug there, but I think they will say that LT seems to be the only plugin causing this issue and therefore say its a LT issue. Will be hard to prove otherwise if there is no other plugin causing that issue.

  1. The dynamic toolbar is a separate issue. You can move it (right click, unfreeze and move it by mouse to where you want it). After a restart, it will open again in the location where you moved it, unless you have reinstalled LT. There is actually a problem if you deactivate it. This is a separate issue. Could you open a new issue for this? I'll take care of it.

I commented in bug 10282.

@ColeBantam
Copy link
Author

  • The first point has now been solved in such a way that if there is not enough heap space, a warning is issued and only the LT spell checker is switched off. Meanwhile, the grammar check continues without restrictions. The LT spell checker can now also be turned on and off in the LT option panel.

Please test both points and provide feedback.

Are these changes already in LanguageTool 6.4-SNAPSHOT (2024-02-25 18:59:28 +0100, 77fff17)?

@FredKruse
Copy link
Contributor

No, it will be in the next snapshot.

@ColeBantam
Copy link
Author

ok, will test tomorrow

@ColeBantam
Copy link
Author

First impression of 'LanguageTool 6.4-SNAPSHOT (2024-02-26 18:59:22 +0100, b0a2047)' in the context of this bug is good. I did get the message about less then 1024MB heapspace and did tests with 512MB as always and with 1024MB and LT-Spellchecker enabled. So far no crashes. But thats realy just after a few minutes.

With the last Snapshot I had a huge crash yesterday evening, with so many lines on it that it didn't fit my 27" screen :D Lets see if this one is more stable ... Ill test with 1024MB and LT-Spellchcker on for the moment, as is closer to the "average user". And so far I don't feel noticeable lag with the bigger LibO-Memory-Footprint.

p-goulart pushed a commit that referenced this issue Mar 7, 2024
p-goulart pushed a commit that referenced this issue Mar 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
office-integration the LibreOffice/OpenOffice add-on
Projects
None yet
Development

No branches or pull requests

4 participants