Bugzilla – Full Text Bug Listing
| Summary: | Juno SR1 freezes on query code generation for simple project | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] Viatra | Reporter: | Joost van Pinxten <joostvanpinxten> | ||||||||||
| Component: | Query | Assignee: | Zoltan Ujhelyi <zoltan.ujhelyi> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Istvan Rath <istvanrath> | ||||||||||
| Severity: | major | ||||||||||||
| Priority: | P3 | CC: | dev, ed, harmath, sebastian.zarnekow | ||||||||||
| Version: | oldinquery | Keywords: | helpwanted | ||||||||||
| Target Milestone: | Future | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows 7 | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 226260 [details]
configuration used for this bug.
The message that stays in the job monitor is "Writing new resource descriptions for...". This also cannot be canceled. Commenting out the imports makes the slow behavior go away. This also happens with the (six) EPackages that I have registered for my own DSL. Did you try to adjust Eclipse's startup parameters as recommended on http://incquery.net/performance ? Specifically, -Xmx and -XX:MaxPermSize are important to set up properly. I did not, but I did now; the problem does not go away. When using unknown import uri's, the "Building workspace" job is still extremely slow (think 2 minutes+) on an otherwise responsive system. Can you reproduce this with the information that I gave? Or does it work as intended for you? On my laptop, the CPU does not go above 20% and the disk is almost idle while it is trying to build the resources. However, I'm not experiencing the freezes on my desktop now (after changing the max memory settings, per your suggestion). I've even updated the full project and that builds in < 10 seconds now. Xtext version is exactly the same, (201208210947). Am in the process of copying the full Eclipse installation to my laptop and see if the problem persists. I don't know how to tell you how this behavior can be reproduced... On my desktop, I don't experience these issues as badly as on my laptop. Copying the workspace from my laptop to my desktop also does not make my desktop Eclipse misbehave. So, what can I check now to see why this Eclipse instance behaves so differently? They now have the same Windows, same Eclipse (including plugins), same Java JRE and JDK... can't figure out what's different (that matters). (In reply to comment #7) > So, what can I check now to see why this Eclipse instance behaves so > differently? > > They now have the same Windows, same Eclipse (including plugins), same Java > JRE and JDK... can't figure out what's different (that matters). If you have time, can you try to create a 3.8 installation on your laptop (with the same plugins as in your 4.x configuration) and check whether the issue is present in that one? I have experienced several similar hard-to-reproduce performance and annoyance issues with 4.2 and I've switched back to 3.8 - I haven't seen any of them there yet. Just found time to install 3.8 with the according plug-ins. As Juno 4.2.1 is unusable on my laptop, I will use Juno 3.8 instead. Thanks for the tip! It may very well be a deeper problem in Juno 4.2 then... (In reply to comment #9) > Just found time to install 3.8 with the according plug-ins. As Juno 4.2.1 is > unusable on my laptop, I will use Juno 3.8 instead. > > Thanks for the tip! It may very well be a deeper problem in Juno 4.2 then... I see that this does not state whether or not this helped explicitly; it did, it is blazing fast again ;-) Thanks for the detailed feedback. Sadly, none of us reproduce your issue (not even in 4.2), so it is really hard to provide a fix. When reading the thread, I was thinking about kind of short-circuiting search for packages - that means, if there are a lot of packages available, they might all be traversed multiple times. But the fact that it is specific to only a single computer with Eclipse 4.2 makes that theory rather weak. So at this moment I suggest leaving this issue open and look for other reproductions of the issue. As this seems to be a hardware/software combination issue, here's my (relevant) hardware configuration (in case someone else bumps into this problem too); -HP EliteBook 8530w -Intel T9600 -Intel 510 SSD -NVidia Quadro FX 770M (In reply to comment #12) In my experience there is a really bad inter-project interaction involving at least UpdateDependencies, PlatformBuilder, EGIT, {XtextIndex/MWE/Acceleo} There was certainly one really bad EGIT bug whereby the builder increments were being mis-propagated. I suspect that there are a few more. I often find it necessary to disable auto-build while projects stabilize then re-enable building. (In reply to comment #13) > (In reply to comment #12) > In my experience there is a really bad inter-project interaction involving > at least > > UpdateDependencies, PlatformBuilder, EGIT, {XtextIndex/MWE/Acceleo} > > There was certainly one really bad EGIT bug whereby the builder increments > were being mis-propagated. I suspect that there are a few more. > > I often find it necessary to disable auto-build while projects stabilize > then re-enable building. Thanks for putting this on your radar too. It seems to be strongly linked to resolving non-existing Ecore URI's, as when these are correct (I've just switched URI's) then it is no longer a big issue. Will also uninstall EGIT and see if that helps in this case. I can confirm the issue with an Xtext project containing 285 files. Each one is selfcontained (no imports of any kind). When building the project, the progress bar hangs at "Writing new resource description for <file> (239 of 385)". The interesting thing is that is seems to hang temporarily at file 40 of 385, but seems to recover somehow. However I can remember that at some day it hang completely at file 40 of 385. "Hang" means that the Building Workspace Job is blocked and is not cancelable. The rest of the UI is still responsive. The Eclipse process takes a whole CPU at 100%. Looking at the number of threads used for a longer time (about 20 minutes), the number decreases from about 60 to 48 (but still 100% CPU usage). Eclipse can not be closed, the only way to get rid of it is to kill the process. I tried to reserve more memory, but with no luck. Current VM arguments are -Xms40m -Xmx1024m -XX:MaxPermSize=512m (before: -Xmx512m -XX:MaxPermSize=256m) Hardware platform is a MacBook Pro with 2.9 GHz i7 and 8 GB RAM. I also tried removing the EGit plugins in my Run Configuration, which did not help. I know it might seem like a drastic "solution", but does going back to 3.8 solve your problem? (In reply to comment #16) > I also tried removing the EGit plugins in my Run Configuration, which did > not help. (In reply to comment #17) > I know it might seem like a drastic "solution", but does going back to 3.8 > solve your problem? I just installed Eclipse 3.8.2 (Build id: M20130131-0800) and Xtext and I experience exactly the same issue (at the same file, 239 of 385). So it seems to be a general problem, not necessarily 4.2-specific... Did you try to profile the issue to get an idea what it does at file 2xx of 3xx? It makes more sense that the issue is not 3.8/4.2-related but it seems some kind of weird race condition. However, as I have not witnessed the issue (Xtext, EGit installed, IncQuery from source), and have no idea where to look in the issue for. But if any information comes forth about how to reproduce the issue, I would be glad to look into it further. Even went back to Eclipse 3.7, but still the same issue, so it's definetely not Eclipse-version-related. Just did a profiler run and will attach some screenshots. But I can't see anything special there (maybe you can?). Would it be useful if I uploaded the xtext projects and the sample source code project so you could test it on your machines? The grammar is for an existing sound synthesis language called SuperCollider (http://supercollider.sourceforge.net/) which is released under the GPL, so I guess it should not be a problem. Created attachment 227974 [details]
Profiling Screenshots
Profiling run with Visual VM while Eclipse hangs at "Writing resource descriptions".
I looked also at the screenshots, and neither did I see anything special - except for the fact that the issue is neither Windows-specific, as you could reproduce it on OS X. If you could upload an example project that produces this hang would be most helpful with some basic steps how to reproduce the issue. Thanks in advance. Created attachment 228024 [details]
Workspaces to reproduce issue
This attachment contains a development and a runtime workspace.
To reproduce the issue, follow these steps:
1. Start an Eclipse 4.2 instance using the development workspace
2. make sure all dependencies (Xtext etc.) are resolved
3. Start the Runtime Eclipse Run Configuration, pointing to the Runtime workspace provided in the zip file
4. Build the project in the runtime workspace and check if the job hangs at "Writing new resource description for file..."
(In reply to comment #24) > Created attachment 228024 [details] > Workspaces to reproduce issue > > This attachment contains a development and a runtime workspace. > To reproduce the issue, follow these steps: > > 1. Start an Eclipse 4.2 instance using the development workspace > 2. make sure all dependencies (Xtext etc.) are resolved > 3. Start the Runtime Eclipse Run Configuration, pointing to the Runtime > workspace provided in the zip file > 4. Build the project in the runtime workspace and check if the job hangs at > "Writing new resource description for file..." Thanks for the case, I could reproduce the hanging using your configuration on file 94 of 379 (MIDIResponder.sc). After some debugging, I found out that the hang happens during parsing; and also found that it was parsing the filer WII.sc. I would try to reduce that file to see whether a) there is a specific construct thats handled badly, or b) the sheer size of the file causes the problem. Sadly, I have no deep knowledge of neither your domain model nor the inside of the Antlr parser used inside Xtext to provide more feedback. On the other hand, this issue tracks the specific hang related to the EMF-IncQuery project, and if I understand it correctly, your project/language does not use that, so I would like to ask to connect the Xtext developers on their forums (or possibly through a ticket if you managed to created a smaller reproducible example with the issue - the current one is simply too large to help efficient debugging). However, thanks again for trying to help us tracking down our freeze. I'm setting version to "unspecified" as we currently do not (firmly) know when these future ideas will be addressed. We have seen this issue again. After some debugging, I have identified two factors that might contribute to the triggering of the problematic case. - using Java 1.6 (.0_45 being the most current version) seems to trigger this problem *much* more frequently, 1.7 seems to be far less problematic. - the hang at "Writing resource description" might be triggered when the disk space under the workspace is running critically low. It indeed seems to be independent of 3.x or 4.x as it was seen on both. (In reply to comment #27) > We have seen this issue again. After some debugging, I have identified two > factors that might contribute to the triggering of the problematic case. > > - using Java 1.6 (.0_45 being the most current version) seems to trigger > this problem *much* more frequently, 1.7 seems to be far less problematic. Just FYI: I had been using Java 1.7 with the 3.8.x and 4.2.x Eclipses. Is it really even worse with Java 1.6? > - the hang at "Writing resource description" might be triggered when the > disk space under the workspace is running critically low. I had 10+ gigabytes left on my disk (only have 1, 1 partition), so that should not have been the cause for my problem. > > It indeed seems to be independent of 3.x or 4.x as it was seen on both. Did you also notice that it was more prominent on 4.x than on 3.x? Or did that not make a difference. Just tested with a JDK 1.7.0_21 on OS X and indeed the issue does not occur now. However, it took a very long time to update all resource descriptions (about 40 minutes for ~400 files), but that might be a problem with my parser (which uses backtracking). I guess disk space and performance is not the problem, since I use an SSD with 300GB free space. I'm tentatively closing this issue. With the new Xtext and the completely rewritten IncQuery Builder for 0.8, these performance problems have been greatly reduced. Unfortunately I experienced this again using EMF-IncQuery 0.8.0, Xtext 2.6.2 and Eclipse 4.3.1. I'm writing ~20 patterns over a huge metamodel and updating the project takes several minutes, with most time spent with "Writing new resource description for <genmodel>.genmodel" and "Compiling patterns.eiq", and sometimes even a modal dialog is shown. |
Created attachment 226259 [details] simple example project that triggers the interface freeze Importing this simple IncQuery project (one with nonsense) into a clean Eclipse Juno Modeling tools, which has only downloaded Xtext SDK and the IncQuery from the Continuous Integration update site will not behave well when generating the code. Just try to modify the file, save it and then within 10 seconds (while the code is being generated) modify and save again. The save action will be delayed until the code has been generated, but this will often completely freeze (white overlay on the window -> not responding) the UI for about 20 seconds. The same happens on my actual project, but while generating/building the code, I am not allowed to open the IncQuery query definition file that is currently generating, as this will also block the Eclipse UI. Will attach the configuration installation details that have been used by Eclipse in another message.