Bugzilla – Full Text Bug Listing
| Summary: | On pause monitoring profiling data is still collected | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Alex Nan <apnan> | ||||||||
| Component: | TPTP | Assignee: | Eugene Chan <ewchan> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||
| Severity: | critical | ||||||||||
| Priority: | P1 | CC: | amehrega, ewchan, guru.nagarajan, jkubasta, samwai, sluiman | ||||||||
| Version: | unspecified | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows Vista | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Alex Nan
Created attachment 71095 [details]
Test application
Attaching a zip containig the sample application used to test the failing scenario.
Raising this to critical, since it's a regression. Alex. This is not a regression. I am able to get 8 instances of the Button class using the 4.3.1, 4.4i2 and 4.4i3 AC drivers. Samson, I tried with a 4.3.1 RAC and client and it works as I expect it to work, the instances that are created duirng the pause are not counted when monitoring is resumed. It looks like the 4.4 client is having differenlty, I tried with 4.4 client and 4.3.1 and also 4.4 RAC and I see the same behaviour that you see, which I believe is wrong. Perhaps the regression is on the client code. Hi Alex. Which component do you think this bug should belong to? Since AC/profiler is sending the same profiling data from 4.3.1 to 4.4, I think this is not an AC/profiler related bug. Thanks. Assign it to Platform.ProfilingPerspective for further investigation. Assigning to "Platform.UI.ProfilingPerspective" for further investigation. I have a question here why is it a client UI problem? The client UI does not create/advance the instance value in the table by itself, but instead shows what it is given from the collector side? If the collector does not stop monitor on request and captures any instance value that it should be ignored and send to the UI, then UI will show what it is given. So from the tests it shows that the 4.4 client behaves differently then the 4.3.1 when using the same 4.3.1 RAC. I am not saying the UI is the problem but the UI is a good place to start tracking the problem since the problem seems to be on the client side. That's fair, it sounds to me the execution framework is not handling the stop monitoring event correctly. I will take a look at the stack between 4.3.1 and 4.4 Other than the manual step of starting the app, this seems to map directly to the profile on server scenario, and it sounds like an agent problem since hte agent has to do special things to be silent while attached. Things like stack tracking etc.. Does this problem occur with profile on server as well/ (In reply to comment #12) Same problem occurs to Profile on Server use cases. I see this problem only occurs to Memory Analysis but not Execution Time Analysis. ie. Instance created during 'pause' period is collected and shown in views, but invocations during the period is not collected nor shown in views. I profiled with JVMPI, I have to verify also on JVMTI. The pause monitoring action goes two different paths for JVMPI and JVMTI. Confirmed with the 0618 driver that problems only exists in PI Memory Analysis, but not PI Execution Analysis, nor TI Memory Analysis and TI Execution Analysis. (In reply to comment #14) > Confirmed with the 0618 driver that problems only exists in PI Memory Analysis, > but not PI Execution Analysis, nor TI Memory Analysis and TI Execution > Analysis. So in end user terms, the problem will only hsow up if doing memory analysis of Java 1.4 because 1.5 and beyond are supported with TI based agents. That's correct. and FYI, I was using IAC, I should also have tested with RAC even though the same agent should be applied and used in both use cases. Same behavior is observed in RAC use cases. ie. Problem exists only with PI Memory Analysis. Alex, I observed the same behavior in both 4.3.1 and 4.4 driver, with their corresponding RAC, which confirms Samson's comment #3, but inconsistent with your comment #4. Would you please confirm that again and maybe explain comment #5? Thanks in advance. Eith a 4.3.1 RAC and 4.3.1 client the memory statistics view doesn't display instances created during the pause time interval. With a 4.3.1 RAC and 4.4 client, the view displays all the instances, including the once created in the pause time interval. With a 4.4 RAC and 4.4 client the same behaviour as in the previous case happens. I was able to reproduce the behaviour described in comment 19 on two windows 2000 machines. The problem also happens on Vista. Note that the scenario uses attach not launch. OK. I talked to Alex. In 4.3.1 (both RAC and Client), the problem does not happen if (1) users select only Memory Analysis, but problem shows up when (23) users select BOTH Memory and Execution Analaysis together. In 4.4 (both RAC and Client), the problem exists in both use case (1) select Memory Analysis only, and (2) select BOTH Memory and Execution Analysis. I checked the call stack of the stop monitoring action code and it's exactly the same between 4.3.1 and 4.4. I suspect it's something with the Collection Mode sent over to the agent which is used back on loading process of data. I will try profile to file and compare the trace data between the 2 releases. With 4.3.1 RAC and 4.4 Client, both (1) select Memory Analysis only and (2) select BOTH Memory and Execution Analysis fails the testcase. Comparing between the trace files of 4.4 client and 4.3.1 client with the same 4.3.1 RAC. There is a different in the option 4.3.1 : <option key="STACK_INFORMATION" value="none"/> 4.4.0 : <option key="STACK_INFORMATION" value="contiguous"/> Created attachment 71792 [details]
patch
patch that fix the regression in use case (1) select Memory Analysis only
Created attachment 71793 [details]
patched jar plugin
Alex, would you please test the patch with this jar plugin?
Samson, For use case (2): select BOTH PI memory and execution analysis, <option key="STACK_INFORMATION" value="normal"/> is sent to agent correctly, but it's treated as <option key="STACK_INFORMATION" value="contiguous"/> Could you take a look at the problem on the agent side? Thanks for your time. Ali, Would you please review the patch in comment #24? I have tested the patch and I confirm that the problem is resolved if using only the MEMORY_ANALYSIS option as explained in the original description of the defect. If both MEMORY_ANALYSIS and EXECUTION_ANALYSIS are used the problem still persists for the memory statistics results. The Execution statistics results are OK. Thanks Alex for testing the fix. Since the problem in use case (1) is a regression. I would like to get approval to have it fix before a complete fix for both use cases (1) and (2) is available. Joanna, please advise? A solution for user case (2) will not be available until comment #26 is resolved. Please request approval. If we can get PMC approval by eod, we should be able to include this patch in 4.4 (In reply to comment #24) > Created an attachment (id=71792) [details] > patch > > patch that fix the regression in use case (1) select Memory Analysis only > Patch is approved by PMC, and submitted to CVS. (In reply to comment #27) > Ali, Would you please review the patch in comment #24? > Sorry for the late reply. I tested and reviewed the patch and it looked fine. Thanks Ali for reviewing the patch. Please resolve this defect as fixed Joanna, only use case (1) is fixed. There is still use case (2) that is valid and not yet fixed. Should I target 4.4.0.1 or reopen a separate bug for the problem? pls open a separate bug targeted to 4.4.0.1 and resolve this defect as fixed. Thanks, Eugene. close this bug, and opened bug 193797 to following up on use case 2. Verified in TPTP-4.4.0-200706140100C. Closing. |