Community
Participate
Working Groups
When I search my Fortran project, I get the usual search results in the search window. When I choose any hit (double clicking), the file is openened at the corresponding location, nothing unusual. But when I try to do that with any further Fortran file in the results list, the eclipse UI freezes with 100% CPU usage of the java process. Peculiar thing: I also have C code in my project. When I choose any search result that is in a C file as the second choice, eclipse does not hang, plus, I may select another search result in a Fortran file afterwards without eclipse hanging. So choosing a C file seems to reset the state somehow. When I choose a Fortran result after this, eclipse hangs again. To sum up: choose result in: 1) f90 2) f90 --> hangs 1) f90 2) c 3) f90 --> ok 4) f90 --> hangs 1) f90 2) c 3) f90 4) c --> ok 1) c 2) c --> ok If you need any further information, I'll try hard to provide it.
I forgot to mention: this happens in both cases, when the Photran indexer (refactoring) is enabled and when it is disabled too.
Please attach a stack trace. For more info see: http://wiki.eclipse.org/index.php/How_to_report_a_deadlock
Created attachment 228344 [details] stacktrace done while eclipse ui was frozen
Version: Juno Service Release 2 Build id: 20130225-0426 java version "1.7.0_17" Java(TM) SE Runtime Environment (build 1.7.0_17-b02) Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) I hope I did that stacktrace correctly and that it is useful. The ui unlocked after some time of being totally unresponsive (~30 s - 1 min, no repainting of the window contents).
(In reply to comment #4) > Version: Juno Service Release 2 > Build id: 20130225-0426 > > java version "1.7.0_17" > Java(TM) SE Runtime Environment (build 1.7.0_17-b02) > Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) > > > > I hope I did that stacktrace correctly and that it is useful. > > The ui unlocked after some time of being totally unresponsive (~30 s - 1 > min, no repainting of the window contents). Looks like you took the stack dump too late: the main thread already looks idle.
Created attachment 228348 [details] stacktrace done while eclipse ui was frozen 2
I've attached another stack trace. I'm not familiar with those stack traces - how can I see whether the main thread is idle, i.e. if the stack trace is of any use? What do I have to look for?
Created attachment 228349 [details] stacktrace done while eclipse ui was frozen 3
Created attachment 228350 [details] stacktrace done while eclipse ui was frozen 3a This is another stack trace from the same freeze event
Created attachment 228352 [details] stacktrace done while eclipse ui was frozen 3b This is yet another stack trace from the same freeze event (#3)
It looks like the SalesScanKeywordRule is slow. This should also be the case if you just open the file via Project Explorer.
No, opening files via Project Explorer is never slow. It only freezes when I jump to items from the Search Results, and, as I mentioned, only starting from the second result I open (which is not necessarily the second hit in the list), plus only for results in Fortran files. And opening a search result from a C file resets this behavior.
Is there anything I could do or any information I could provide in order to help tackle this problem?
The behavior described in this bug is still the same in the Kepler release (Photran 8.1.0). Due to this bug, Juno+ is unusable for my large Fortran project so I still have to use the Indigo release.
Created attachment 236198 [details] Thread dump done for the kepler release, SR1, Photran 8.1.3
I was having a poke around but couldn't get this to happen for me. What type of search are you doing when you "search my Fortran project"? Can you provide some more detailed steps to make it reproducable?
I'll have to look the exact settings up tomorrow, but some infos up front: The code base has about 500000 lines of fortran code (and some c code) and I have a few different branches in my workspace. When I say I "search the project", I use the "File Search" with certain "File name patterns" (*.f90, *.c, *.h) and a "Working Set" configured to include all files under the source tree of one specific branch (e.g. 'head'). So I just hit CTRL+H, enter a search string into the Containing Text field and hit enter. I then get the results (probably from different files) listed in the "Search" tab I have in bottom of my project view ('search term' - x matches in working set 'head' (*.f90, *.c, *.h). I then select the results from this Search tab in the manner described in my previous comments. Is there anything wrong/suspicious with the procedure I described so far?
Same problem with Kepler SR2, Photran 8.1.4. When I don't have Photran installed, jumping to any Fortran file from the File Search results is extremely quick, but, alas, I don't get any syntax highlighting! Is there any way to get Fortran syntax highlighting without installing Photran?
Bug 388910 obviously describes the same problems I'm experiencing.
Same for Luna (Photran 8.2). Note that when choosing different search results in the same file, this is quick/responsive but only going to a search result in a different file triggers the high CPU load/unresponsiveness.
Hi Thomas -- Is there a relationship between the time to open the search result and the number of lines in the Fortran file? I.e., is it faster if the second search result contains only, say, 5 lines?
Yes, I think I have noticed that tendency. But strangely, this only happens when opening the files from the search results (i.e. jumping to a certain location in the file). Jumping to a second, third etc. result in the *same* file, however, is quick.
Same for Luna SR1 (Photran 9.0.0).
Still unusable in Mars (Photran 9.1).
Just for reference purposes for anyone having the same problem: I got syntax highlighting for Fortran files using the Colorer plugin (I had to install an eclipse version not including Photran since I was unable to disable/uninstall Photran from my Eclipse PTP version). http://www.ohadsoft.com/2012/05/adding-syntax-highlighting-for-new-languages-to-eclipse-with-the-colorer-library/ The Fortran syntax highlighting of Colorer is not as complete as the one included in Photran, but in principle, it could be extended (which I'll probably try once I can find the time to). With this workaround, I have syntax highlighting plus I can jump quickly to search results located in Fortran files.
Unfortunately, the syntax colorer plugin didn't prove to be a good solution... *sigh* I want to offer once again to provide debugging information (stacktraces, whatever it takes) to help to find and correct this long standing problem. Unfortunately, I cannot fix this myself )o;
There was no update of Photran for the Neon release, so the problem is still the same there. Indigo works for me – that's fine; still, I beg anyone who is familiar with the Photran code: please have a look at this issue again. I'll do my part and try to provide whatever it takes to tackle it.
I've managed to reproduce the problem with an open source fortran project from here: git clone https://github.com/astrofrog/fortranlib.git I imported the project into a new workspace 1) New | Project | General > Project 2) Next 3) Project name: fortranlib 4) Next Execute a search: 1) Ctrl-H 2) File search in * for Containing text: module 3) From the list of hits I selected in base_types.f90 the hit in line 28 -> good, quick) 4) From the list of hits I selected in file lib_hdf5.f90 the hit in line 303 -> GUI freezes for quite some time
It looks like there is a performance issue in the Fortran scanner, possibly related to the Sales algorithm implementation (since that is where the code always seems to be stopped). I noticed that it took longer and longer for the file to open depending on the number of matches (probably related to the file size - larger file, more hits for the keyword). More investigation needs to be done to see where in org.eclipse.photran.internal.ui.editor.SalesScanKeywordRule all the time is being spent (it looks like SalseScanner#scan() is pretty inefficient).
What puzzles me is that it's not slow when opening Fortran files from the project explorer and why, when opening from the Search windows, choosing C files intermediately seems to reset the slowness when opening Fortran files.
By the way thanks for looking into it again! I assume you could reproduce the problem with the steps listed in comment #28…?
(In reply to Thomas Mitterfellner from comment #31) > By the way thanks for looking into it again! I assume you could reproduce > the problem with the steps listed in comment #28…? Yes, I was using your steps to reproduce.
(In reply to Thomas Mitterfellner from comment #30) > What puzzles me is that it's not slow when opening Fortran files from the > project explorer and why, when opening from the Search windows, choosing C > files intermediately seems to reset the slowness when opening Fortran files. I also noticed that opening the file from the project explorer does not have the performance problem. It must be something to do with the way the search view is opening the editor, although it seems to be called from the same path in most cases: o.e.jface.text.rules.DefaultDamageRepairer#createPresentation().
Same problem for oxygen (photran 9.1.3) – *sigh* I'd be really grateful if someone could look at this problem again and hopefully come up with some fix. I would have a spin at it myself but I have no experience with java and have no idea where/how to start. The only thing I can definitely offer is to provide yet more debugging info, though the test case/instructions I provided above make it possible to reproduce the issue for anyone willing, using an open source project.
I also experience the same bug, with Eclipse Neon.3. If, in the search view, I open a fortran file with more than 4000 lines, Eclipse freezes for tens of seconds. No problem if I open the same file from Project Explorer. I disabled C folding in the preferences, but this has not had any effect. Please tell me how I can contribute to debug this issue (but I would need detailed instructions...). This is the most annoying bug in Photran for me now.
I will try to look at it again
I am willing to give 150 € to the kind person that fixes this long-standing bug for me. I really mean that.
I would love to fix this, notwithstanding the offer. I will try to carve out some time to look at it again.
Would anyone care to take a look at this problem again?
I wish someone would :-/. FYI, we're trying to get funding to revive PTP (inc. Fortran) in some form using the language server protocol (LSP). Will keep the community posted when something happens....
