Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 330359

Summary:

Multiple scanner discovery parsers running for RDp remote CPP project

Product:

[Tools] PTP

Reporter:

John Liu <john_ws_liu>

Component:

RDT

Assignee:

Chris Recoskie <recoskie>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

ptp-inbox, recoskie, vivkong

Version:

unspecified

Target Milestone:

4.0.6

Hardware:

OS:

Windows XP

See Also:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=330704

Whiteboard:

Attachments:

Description	Flags
applied to rdt.core	none
Updated patch - removing unnecessary function arguments	recoskie: iplog+

Description John Liu

2010-11-16 09:43:01 EST

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

Comment 1 John Liu

2010-11-16 09:52:57 EST

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.

Comment 2 John Liu

2010-11-17 11:14:24 EST

Created attachment 183310 [details]
Updated patch - removing unnecessary function arguments

Comment 3 Chris Recoskie

2010-11-19 14:14:42 EST

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.

Comment 4 John Liu

2010-11-19 14:37:12 EST

(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