Community
Participate
Working Groups
Build Identifier: In a RDp Cpp project, 6 scanner discovery parsers are found running during the build, 3 layers of output stream are created to read build output, in which each stream contains 2 scanner discovery parsers(one for c source input and one for cpp source input) These 6 scanner discovery parser do the identical job, they waste a lot time and memory, it actually causes out of memory issue in my test for some large projects. Reproducible: Always
Created attachment 183226 [details] applied to rdt.core The fix reduces any duplicate scanner id in RemotemakeBuilder and check if the generated parsers are the same in ScannerInfoUtility and skip any duplicate parsers. So after patch we only have one parser running for build output.
Created attachment 183310 [details] Updated patch - removing unnecessary function arguments
Applied to ptp_4_0 and HEAD. We're going to have to revisit the contexts issue though when we support the GNU tools. The check the patch does checks to see if the context results in the same parser, but the parser may actually parse differently depending on the context. That's the whole point of the contexts. For XLC it's a moot point because the parser ignores the context. So even though I think this needs further work, I'm checking this in to get an interim fix in for the deadline. I suggest John you look into context issue with the GNU parsers and file new bugs as appropriate.
(In reply to comment #3) > Applied to ptp_4_0 and HEAD. > We're going to have to revisit the contexts issue though when we support the > GNU tools. The check the patch does checks to see if the context results in > the same parser, but the parser may actually parse differently depending on the > context. That's the whole point of the contexts. > For XLC it's a moot point because the parser ignores the context. > So even though I think this needs further work, I'm checking this in to get an > interim fix in for the deadline. I suggest John you look into context issue > with the GNU parsers and file new bugs as appropriate. Yep, I will check it again when we support GNU parsers. Open a bugzilla to keep track of this future work. https://bugs.eclipse.org/bugs/show_bug.cgi?id=330704
