OutOfMemoryError after editing a file with custom XML schema for a while #489
Comments
Could you send me your XMl and XML Schema files and XML catalog please. |
|
I sent you an email. Thanks for looking into this! (Trying to reproduce this may take a lot of patience – I haven't been able to trigger this intentionally within 15 minutes, but I get it multiple times a day while working on the XML document. If there's any useful additional logging I could turn on, let me know!) |
|
I suspect the problem comes from outline. I suggest several solutions:
|
|
Thanks! I've disabled the outline (using the extension's setting) – I'll report back once the issue re-occurs, or in about a week if it doesn't.
Is there any specific change you suggest? As mentioned, I already set |
|
Unfortunately, it looks like this wasn't the (only) cause. Despite the outline being disabled (which seems to have worked – the outline view now shows “no symbols found”), I got another memory exhaustion. |
|
Thanks for your feedback! It's difficultto reproduce it since we should update the XML file while several minutes.
@rgrunber can you clarify that please?
I'm confused, did you start the XML Server with Jav aor with binary? An interesting test is to try to update XML without XSD link. Do you think you could try it? |
I understand – if I ever find a way to reproduce this reliably, I'll let you know.
I didn't configure anything for this, it just worked. I had installed Java anyways, and based on my reading of the settings, since I did not enable I've now toggled the settings to prefer the binary, VS Code is now spawning
I can try. Since this is somewhat annoying (I still don't know my XML Schema by heart), I'll try this after I crashed the binary version (or concluded that it works). |
|
Thanks! |
|
I see there's some suggestions being tried that might fix things, but I wanted to comment on the memory situation since this is very similar to what I've seen in another plugin ( redhat-developer/vscode-java#1262 ). The default JVM options were meant to optimize for an application that is always doing some processing. While language servers do some intense processing initially (eg. import the project/xml file, the above attached chart shows this nicely), they quiet down significantly afterwards, so it's a good opportunity to do garbage collection. Basically, I would try something like : Some may wonder why we don't make that the default. These options are specific to OpenJDK ( #278 ) and we ultimately decided to support more Java runtimes, while giving people the option to configure individually. A good reference is : |
|
Thanks for the input! I'll add that to my list of things to try (which takes time due to the issue only occurring irregularly) – but it seems like this would make sense if the problem was that memory consumption slowly grew without every being garbage collected properly. I don't think that's the case her: I've never seen the |
|
After some days of editing, it looks like the binary version is completely stable for me. For testing, I'll now return to the Java version, this time using the configuration recommended by @rgrunber ( |
Thanks so much! Your feedback is really important because if it works for you, we could define this setting as default. Thanks again for your patience! |
|
Hm, RAM usage looked OK:
However, this time, there was no Based on timing, the last messages happend just before the problem occurred.
...but I just realized that I configured the wrong setting |
|
An update: After setting the correct arguments, i.e. I'll keep things configured like so and report back if I ever experience another memory problem, but I'm expecting to mostly work on other things for a while, so I'll be giving it fewer chances to crash in the nearer future.
Maybe the extension could try to detect the JVM in use and use appropriate defaults (or just try passing these arguments by default, and re-try launching the JVM without them if it immediately quits with an error code)? |
|
We might do well to look at what ends up happening in redhat-developer/vscode-java#1959 . In addition to more elegantly reporting OOM events to users, there was discussion about simply restarting the language server by upping Xmx by say, 200MB if the previous crash was an OOM. We already have code to restart on a crash so it seems possible. For now I'll mark this as an enhancement for better handling of OOM events. |
|
vscode-xml should now have the capability to detect OOM errors and handle them more gracefully when using the Java version of the XML language server. With that said it does seem like this isn't so much of an issue for the binary version. We can work on further improvements like automatically incrementing the amount of memory allocated to the JVM. |
|
Thank you for working on this ❤️ |
For me, this extension regularly runs into OOM errors.
I'm editing a moderately-sized XML file (1 500 lines, 130 KB) that uses a custom XML schema (of about 300 lines). This works well, and I receive proper IntelliSense suggestions and schema violation errors, until, after some amount of editing, the extension seems to run inte an OutOfMemory error:
From that point on, suggestions and problems stop working until I restart VS code, which fixes the issue until it re-occurs after a few minutes to about an hour. I haven't found a targeted way to trigger the behavior, it just seems to occur after some time of editing.
After the problem has occurred, the
java.exeprocess seems to only take about 200 MB of RAM, the same it does after starting up.Watching the memory usage during normal operation doesn't show any egregious memory problem (and any activity in this graph coincided with some typing activity):
Here's some details about my setup:
xml.catalogssetting to contain a single entry, an XML catalog mapping a single name to my XML schema definition.xml.server.binary.argsto-Xmx1gto no avail.I'm not sure what else I can do to help debug this – if needed, I can share my XML schema and the document I'm editing, but I'd prefer not to post this publicly (sorry).
The text was updated successfully, but these errors were encountered: