| Summary: | [transport] Transport SendData returns -1 and causes trace events loss | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Ruslan Scherbakov <ruslan.scherbakov> | ||||||||||
| Component: | TPTP | Assignee: | Igor Alelekov <igor.alelekov> | ||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||
| Severity: | critical | ||||||||||||
| Priority: | P1 | CC: | asaf.yaffe, guru.nagarajan, jgwest, jkubasta, ruslan.scherbakov, samwai, sluiman, viacheslav.g.rybalov | ||||||||||
| Version: | unspecified | ||||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | closed460 | ||||||||||||
| Bug Depends on: | |||||||||||||
| Bug Blocks: | 190687 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Ruslan Scherbakov
Ruslan, could you tell what is the Java2Demo.jar? Please submit a servicelog.log dile with DEBUG level. Created attachment 71830 [details]
Java2Demo.jar
Created attachment 71833 [details]
servicelog.log
with sun-jre1.5.0_11-win-ia32
and agntctrl.win_ia32-TPTP-4.4.0-200706180100
Thanks, once more question :) How it could be seen that "Next ~60 are lost"? Created attachment 71835 [details]
Profiler outputs
The missed events can be found in the attached dump_1182247475343_trace.trcxml by -1 indication in format:
...
<classDef name="[F" sourceName="<Unknown>" classId="2147483649" time="1182247474.587285694"/>
99=-1
...
This events do not reach the client (dump_1182247475343_1.out) and client socket (dump_1182247475273_3.out).
Created attachment 71874 [details]
patch
jvmti.runtime patch Ruslan reviewed and tested
(In reply to comment #6) > Created an attachment (id=71874) [details] > patch > jvmti.runtime patch Ruslan reviewed and tested I don't claim to understand the general code base, but this patch basically reduces the number cases a variable is set. So I am curious how much testing was done for all the "else" cases that are now exposed. Does the data listener only need to be set for this one command? Currently, several clients (5) attach to the agent and send resume/run.. commands simultaneously. Only one client establishes data channel. Variable m_dataListenerID should be initialized with this data channel id. But currently it is set with every incomming command from all clients. And agent tries to send data to the originator of the last command. And if it hasn't data channel, data are lost. The patch allows sending data on last established data channel only. (In reply to comment #8) > Currently, several clients (5) attach to the agent and send resume/run.. > commands simultaneously. > Only one client establishes data channel. Variable m_dataListenerID should be > initialized with this data channel id. But currently it is set with every > incomming command from all clients. And agent tries to send data to the > originator of the last command. And if it hasn't data channel, data are lost. > The patch allows sending data on last established data channel only. Thanks, this is the logic I was expecting. The issue then becomes testing since there may be problem that have been dependent on or hidden by the behaviour that is being fixed. Please don't let Comment #9 deter you from checking in the patch. With *every* patch that fixes a grave bug by which some function did not work at all, there is the problem that the grave bug might have masked some other bugs in that function. These bugs will only become apparent after the patch has been checked in, and it is not the patcher's responsibility to test for possible further bugs that had been masked. [I need to profile JVM 1.6 machines with JVMTI and am currently blocked by the dependent bug 190687.] (In reply to comment #10) I agree Oliver. My questions about testing are actually to the folks that will role this fix in and if it can be contained in the Europa driver we are supposed to provide today, and not at all a question of taking the fix. To be delivered in 4.4 Samson, please commit the patch and resolve the defect as the PMC has approved inclusion of this fix in 4.4 Patch checked into CVS 2007/06/21 10:30 EDT. As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. |