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

Bug 333908

Summary: Profiling launch no longer maintains individual profiling type settings
Product: z_Archived Reporter: Jonathan West <jgwest>
Component: TPTPAssignee: Mike Reid <mikereid>
Status: CLOSED FIXED QA Contact: Kathy Chan <kathy>
Severity: normal    
Priority: P2 CC: jcayne, jgwest, mikereid
Version: unspecifiedFlags: jgwest: review+
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Patch none

Description Jonathan West CLA 2011-01-10 15:25:03 EST 
In the profile configurations dialog, all launch entries now seem to share a global profile setting (e.g. execution analysis, memory analysis), such that changing one seems to affect all the others.

To Reproduce:
1. In the profile configurations dialog create two launch entries (any launch type will do, for example Java Application/Eclipse Application, etc). One will be used for Execution profiling, the other should be Memory profiling.
2. On the first launch entry, and set the profiling type to 'Execution Analysis'. Click Apply.
3. Move to the second launch entry, and set the profiling type to 'Memory Analysis'. Click Apply.
4. Move back to the first launch entry, and see that it has changed to 'Memory Analysis'.

As it stands the launch types seem to share a global property, which was not previously the case.
Comment 1 Jonathan West CLA 2011-01-10 15:26:24 EST 
I've gone through and tested the previous releases: it works as expected in 4.6.2, does not work in 4.7.0. I've compared the source changes made between the two releases, and my guess at the culprit is bug 313437 (or maybe bug 299294).

Mike, can you take a look?
Comment 2 Mike Reid CLA 2011-01-10 16:16:05 EST 
Indeed looks like bug 313437 is the culprit. Seems to be fixed by explicitly calling initializeAfterFetch() from lazyUpdateDataCollectors() in the case where the host and port are identical.

This has the effect of skipping the data collector fetch (which is what fixed the accessibility bug) but still performing the 'after fetch' logic, which initializes the data collector tree from the launch config.

I'll do some more testing to try and confirm this does not introduce any new wackiness.
Comment 3 Kathy Chan CLA 2011-01-10 17:00:42 EST 
Since this is a regression from 4.6.2, let's try to get this into 4.7.2.
Comment 4 Mike Reid CLA 2011-01-11 10:37:04 EST 
Created attachment 186512 [details]
Patch

Attaching patch.

I did some further testing, things look good. Also confirmed this does not regress the accessibility bug.
Comment 5 Mike Reid CLA 2011-01-11 10:37:41 EST 
Jon, could you review the attached patch for 4.7.2?
Comment 6 Jonathan West CLA 2011-01-11 12:37:12 EST 
Patch is good.
Comment 7 Kathy Chan CLA 2011-01-12 11:17:58 EST 
Project approved for 4.7.2.  Please update the copyright year to 2011 before checking in.
Comment 8 Mike Reid CLA 2011-01-12 11:28:26 EST 
Checked into HEAD.
Comment 9 Jonathan West CLA 2011-04-01 14:21:39 EDT 
Closing.