You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Oliver Deakin (JIRA)" <ji...@apache.org> on 2009/07/17 14:59:15 UTC
[jira] Created: (HARMONY-6274) [jdwp][java6] Garbled output in JDWP
trace
[jdwp][java6] Garbled output in JDWP trace
------------------------------------------
Key: HARMONY-6274
URL: https://issues.apache.org/jira/browse/HARMONY-6274
Project: Harmony
Issue Type: Bug
Components: JDK
Reporter: Oliver Deakin
When launching with JDWP trace turned on (for example, java -Xrunjdwp:transport=dt_socket,suspend=n,server=y,trace=all HelloWorld) the trace output contains garbled content:
12:49:.625 FUNC: [PacketDispatcher.cpp:229] >> Clean(22DE7AE8)
12:49:.625 PROG: [PacketDispatcher.cpp:231] Clean: clean internal data
12:49:.625 MEM: [AgentBase.h:316] VM free: 22D60520
12:49:.625 MEM: [AgentBase.h:316] VM free: 22D60590
12:49:?12:49:.625 FUNC: [ThreadManager.cpp:202] >> Clean(22DE7AE8)
12:49:.625 MEM: [AgentBase.h:316] VM free: 22D43108
12:49:.625 MEM: [AgentBase.h:316] VM free: 22D43980
12:49:?12:49:.625 FUNC: [RequestManager.cpp:57] >> Clean(22DE7AE8)
12:49:.625 MEM: [AgentBase.h:316] VM free: 22D435A8
12:49:.625 MEM: [AgentBase.h:316] VM free: 22D43598
12:49:.625 MEM: [AgentBase.h:316] VM free: 22D435B8
12:49:?12:49:?12:49:?12:49:?12:49:?12:49:e: 22DVM free: 22D61FA8.625 MEM: [Age
ntBase.h:316] VM free: 22D61FA8
12:49:e: 22DVM free: 22D430E8.625 MEM: [AgentBase.h:316] VM free: 22D430E8
12:49:e: 22DVM free: 22D61FD8.625 MEM: [AgentBase.h:316] VM free: 22D61FD8
12:49:?12:49:912:49:‼.625 FUNC: [ClassManager.cpp:112] << Clean()
12:49:e: 22D<< Clean().625 FUNC: [AgentManager.cpp:113] << Clean()
12:49: cleanVM free: 0048E500.625 MEM: [AgentBase.h:316] VM free: 0048E500
12:49:.625 MEM: [AgentBase.h:316] VM free: 0047B070
12:49:.625 MEM: [AgentBase.h:316] VM free: 004974A8
12:49:‼.625 MEM: [AgentBase.h:316] VM free: 22D61190
12:49:‼.625 MEM: [TransportManager.cpp:69] VM free: 22D61320
12:49:‼.625 MEM: [TransportManager.cpp:38] VM free: 22DEEEB8
12:49:.625 MEM: [TransportManager.cpp:38] VM free: 22D437F0
12:49::49:.625 MEM: [TransportManager.cpp:38] VM free: 22D49200
12:49::49::4VM free: 22D61250.625 MEM: [TransportManager.cpp:38] VM free: 22D6
1250
12:49:2D6132VM free: 0047A958.625 MEM: [AgentBase.h:316] VM free: 0047A958
12:49:2D6132VM free: 00496740.625 MEM: [AgentBase.h:316] VM free: 00496740
12:49:2D6132VM free: 0047A0A8.625 MEM: [AgentBase.h:316] VM free: 0047A0A8
12:49:2D6132VM free: 0048E570.625 MEM: [AgentBase.h:316] VM free: 0048E570
12:49:2D6132VM free: 0047B048.625 MEM: [AgentBase.h:316] VM free: 0047B048
12:49:?12:49:?12:49: free:VM free: 00479EA0.625 MEM: [AgentBase.h:316] VM free
: 00479EA0
12:49:e:VM fVM free: 00497530.625 MEM: [AgentBase.h:316] VM free: 00497530
It looks like it is the timestamp parsing that is causing the problem, in particular the seconds part. If I change the timestamp %H:%M:%S to %H:%M then the output is as expected, so I think there is a bug in hystr_ftime() when parsing and replacing the %S token.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HARMONY-6274) [jdwp][java6] Garbled output in
JDWP trace
Posted by "Oliver Deakin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oliver Deakin resolved HARMONY-6274.
------------------------------------
Resolution: Fixed
Fix Version/s: 5.0M11
Fix applied to HEAD stream at repo revision r795108 as it is a bug in both HEAD and java 6 branch.
> [jdwp][java6] Garbled output in JDWP trace
> ------------------------------------------
>
> Key: HARMONY-6274
> URL: https://issues.apache.org/jira/browse/HARMONY-6274
> Project: Harmony
> Issue Type: Bug
> Components: JDK
> Reporter: Oliver Deakin
> Assignee: Oliver Deakin
> Fix For: 5.0M11
>
>
> When launching with JDWP trace turned on (for example, java -Xrunjdwp:transport=dt_socket,suspend=n,server=y,trace=all HelloWorld) the trace output contains garbled content:
> 12:49:.625 FUNC: [PacketDispatcher.cpp:229] >> Clean(22DE7AE8)
> 12:49:.625 PROG: [PacketDispatcher.cpp:231] Clean: clean internal data
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D60520
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D60590
> 12:49:?12:49:.625 FUNC: [ThreadManager.cpp:202] >> Clean(22DE7AE8)
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D43108
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D43980
> 12:49:?12:49:.625 FUNC: [RequestManager.cpp:57] >> Clean(22DE7AE8)
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D435A8
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D43598
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D435B8
> 12:49:?12:49:?12:49:?12:49:?12:49:?12:49:e: 22DVM free: 22D61FA8.625 MEM: [Age
> ntBase.h:316] VM free: 22D61FA8
> 12:49:e: 22DVM free: 22D430E8.625 MEM: [AgentBase.h:316] VM free: 22D430E8
> 12:49:e: 22DVM free: 22D61FD8.625 MEM: [AgentBase.h:316] VM free: 22D61FD8
> 12:49:?12:49:912:49:‼.625 FUNC: [ClassManager.cpp:112] << Clean()
> 12:49:e: 22D<< Clean().625 FUNC: [AgentManager.cpp:113] << Clean()
> 12:49: cleanVM free: 0048E500.625 MEM: [AgentBase.h:316] VM free: 0048E500
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 0047B070
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 004974A8
> 12:49:‼.625 MEM: [AgentBase.h:316] VM free: 22D61190
> 12:49:‼.625 MEM: [TransportManager.cpp:69] VM free: 22D61320
> 12:49:‼.625 MEM: [TransportManager.cpp:38] VM free: 22DEEEB8
> 12:49:.625 MEM: [TransportManager.cpp:38] VM free: 22D437F0
> 12:49::49:.625 MEM: [TransportManager.cpp:38] VM free: 22D49200
> 12:49::49::4VM free: 22D61250.625 MEM: [TransportManager.cpp:38] VM free: 22D6
> 1250
> 12:49:2D6132VM free: 0047A958.625 MEM: [AgentBase.h:316] VM free: 0047A958
> 12:49:2D6132VM free: 00496740.625 MEM: [AgentBase.h:316] VM free: 00496740
> 12:49:2D6132VM free: 0047A0A8.625 MEM: [AgentBase.h:316] VM free: 0047A0A8
> 12:49:2D6132VM free: 0048E570.625 MEM: [AgentBase.h:316] VM free: 0048E570
> 12:49:2D6132VM free: 0047B048.625 MEM: [AgentBase.h:316] VM free: 0047B048
> 12:49:?12:49:?12:49: free:VM free: 00479EA0.625 MEM: [AgentBase.h:316] VM free
> : 00479EA0
> 12:49:e:VM fVM free: 00497530.625 MEM: [AgentBase.h:316] VM free: 00497530
> It looks like it is the timestamp parsing that is causing the problem, in particular the seconds part. If I change the timestamp %H:%M:%S to %H:%M then the output is as expected, so I think there is a bug in hystr_ftime() when parsing and replacing the %S token.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-6274) [jdwp][java6] Garbled output in
JDWP trace
Posted by "Oliver Deakin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732551#action_12732551 ]
Oliver Deakin commented on HARMONY-6274:
----------------------------------------
This is caused by an off-by-one error in hystrftime. In the case of the %S token we check in hystrftime that:
if (index + 2 >= bufLen - 1)
{
return bufLen;
}
and this was the case we were hitting, returning early from hystrftime before inserting the second digits. This if clause should actually be (index + 2 >= bufLen), and there is a similar error in all the token cases in hystrftime. Fixing this check fixes the JDWP trace output..
> [jdwp][java6] Garbled output in JDWP trace
> ------------------------------------------
>
> Key: HARMONY-6274
> URL: https://issues.apache.org/jira/browse/HARMONY-6274
> Project: Harmony
> Issue Type: Bug
> Components: JDK
> Reporter: Oliver Deakin
>
> When launching with JDWP trace turned on (for example, java -Xrunjdwp:transport=dt_socket,suspend=n,server=y,trace=all HelloWorld) the trace output contains garbled content:
> 12:49:.625 FUNC: [PacketDispatcher.cpp:229] >> Clean(22DE7AE8)
> 12:49:.625 PROG: [PacketDispatcher.cpp:231] Clean: clean internal data
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D60520
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D60590
> 12:49:?12:49:.625 FUNC: [ThreadManager.cpp:202] >> Clean(22DE7AE8)
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D43108
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D43980
> 12:49:?12:49:.625 FUNC: [RequestManager.cpp:57] >> Clean(22DE7AE8)
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D435A8
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D43598
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D435B8
> 12:49:?12:49:?12:49:?12:49:?12:49:?12:49:e: 22DVM free: 22D61FA8.625 MEM: [Age
> ntBase.h:316] VM free: 22D61FA8
> 12:49:e: 22DVM free: 22D430E8.625 MEM: [AgentBase.h:316] VM free: 22D430E8
> 12:49:e: 22DVM free: 22D61FD8.625 MEM: [AgentBase.h:316] VM free: 22D61FD8
> 12:49:?12:49:912:49:‼.625 FUNC: [ClassManager.cpp:112] << Clean()
> 12:49:e: 22D<< Clean().625 FUNC: [AgentManager.cpp:113] << Clean()
> 12:49: cleanVM free: 0048E500.625 MEM: [AgentBase.h:316] VM free: 0048E500
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 0047B070
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 004974A8
> 12:49:‼.625 MEM: [AgentBase.h:316] VM free: 22D61190
> 12:49:‼.625 MEM: [TransportManager.cpp:69] VM free: 22D61320
> 12:49:‼.625 MEM: [TransportManager.cpp:38] VM free: 22DEEEB8
> 12:49:.625 MEM: [TransportManager.cpp:38] VM free: 22D437F0
> 12:49::49:.625 MEM: [TransportManager.cpp:38] VM free: 22D49200
> 12:49::49::4VM free: 22D61250.625 MEM: [TransportManager.cpp:38] VM free: 22D6
> 1250
> 12:49:2D6132VM free: 0047A958.625 MEM: [AgentBase.h:316] VM free: 0047A958
> 12:49:2D6132VM free: 00496740.625 MEM: [AgentBase.h:316] VM free: 00496740
> 12:49:2D6132VM free: 0047A0A8.625 MEM: [AgentBase.h:316] VM free: 0047A0A8
> 12:49:2D6132VM free: 0048E570.625 MEM: [AgentBase.h:316] VM free: 0048E570
> 12:49:2D6132VM free: 0047B048.625 MEM: [AgentBase.h:316] VM free: 0047B048
> 12:49:?12:49:?12:49: free:VM free: 00479EA0.625 MEM: [AgentBase.h:316] VM free
> : 00479EA0
> 12:49:e:VM fVM free: 00497530.625 MEM: [AgentBase.h:316] VM free: 00497530
> It looks like it is the timestamp parsing that is causing the problem, in particular the seconds part. If I change the timestamp %H:%M:%S to %H:%M then the output is as expected, so I think there is a bug in hystr_ftime() when parsing and replacing the %S token.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (HARMONY-6274) [jdwp][java6] Garbled output in JDWP
trace
Posted by "Oliver Deakin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oliver Deakin closed HARMONY-6274.
----------------------------------
Resolved, closing...
> [jdwp][java6] Garbled output in JDWP trace
> ------------------------------------------
>
> Key: HARMONY-6274
> URL: https://issues.apache.org/jira/browse/HARMONY-6274
> Project: Harmony
> Issue Type: Bug
> Components: JDK
> Reporter: Oliver Deakin
> Assignee: Oliver Deakin
> Fix For: 5.0M11
>
>
> When launching with JDWP trace turned on (for example, java -Xrunjdwp:transport=dt_socket,suspend=n,server=y,trace=all HelloWorld) the trace output contains garbled content:
> 12:49:.625 FUNC: [PacketDispatcher.cpp:229] >> Clean(22DE7AE8)
> 12:49:.625 PROG: [PacketDispatcher.cpp:231] Clean: clean internal data
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D60520
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D60590
> 12:49:?12:49:.625 FUNC: [ThreadManager.cpp:202] >> Clean(22DE7AE8)
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D43108
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D43980
> 12:49:?12:49:.625 FUNC: [RequestManager.cpp:57] >> Clean(22DE7AE8)
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D435A8
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D43598
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D435B8
> 12:49:?12:49:?12:49:?12:49:?12:49:?12:49:e: 22DVM free: 22D61FA8.625 MEM: [Age
> ntBase.h:316] VM free: 22D61FA8
> 12:49:e: 22DVM free: 22D430E8.625 MEM: [AgentBase.h:316] VM free: 22D430E8
> 12:49:e: 22DVM free: 22D61FD8.625 MEM: [AgentBase.h:316] VM free: 22D61FD8
> 12:49:?12:49:912:49:‼.625 FUNC: [ClassManager.cpp:112] << Clean()
> 12:49:e: 22D<< Clean().625 FUNC: [AgentManager.cpp:113] << Clean()
> 12:49: cleanVM free: 0048E500.625 MEM: [AgentBase.h:316] VM free: 0048E500
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 0047B070
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 004974A8
> 12:49:‼.625 MEM: [AgentBase.h:316] VM free: 22D61190
> 12:49:‼.625 MEM: [TransportManager.cpp:69] VM free: 22D61320
> 12:49:‼.625 MEM: [TransportManager.cpp:38] VM free: 22DEEEB8
> 12:49:.625 MEM: [TransportManager.cpp:38] VM free: 22D437F0
> 12:49::49:.625 MEM: [TransportManager.cpp:38] VM free: 22D49200
> 12:49::49::4VM free: 22D61250.625 MEM: [TransportManager.cpp:38] VM free: 22D6
> 1250
> 12:49:2D6132VM free: 0047A958.625 MEM: [AgentBase.h:316] VM free: 0047A958
> 12:49:2D6132VM free: 00496740.625 MEM: [AgentBase.h:316] VM free: 00496740
> 12:49:2D6132VM free: 0047A0A8.625 MEM: [AgentBase.h:316] VM free: 0047A0A8
> 12:49:2D6132VM free: 0048E570.625 MEM: [AgentBase.h:316] VM free: 0048E570
> 12:49:2D6132VM free: 0047B048.625 MEM: [AgentBase.h:316] VM free: 0047B048
> 12:49:?12:49:?12:49: free:VM free: 00479EA0.625 MEM: [AgentBase.h:316] VM free
> : 00479EA0
> 12:49:e:VM fVM free: 00497530.625 MEM: [AgentBase.h:316] VM free: 00497530
> It looks like it is the timestamp parsing that is causing the problem, in particular the seconds part. If I change the timestamp %H:%M:%S to %H:%M then the output is as expected, so I think there is a bug in hystr_ftime() when parsing and replacing the %S token.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-6274) [jdwp][java6] Garbled output in
JDWP trace
Posted by "Oliver Deakin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oliver Deakin reassigned HARMONY-6274:
--------------------------------------
Assignee: Oliver Deakin
> [jdwp][java6] Garbled output in JDWP trace
> ------------------------------------------
>
> Key: HARMONY-6274
> URL: https://issues.apache.org/jira/browse/HARMONY-6274
> Project: Harmony
> Issue Type: Bug
> Components: JDK
> Reporter: Oliver Deakin
> Assignee: Oliver Deakin
>
> When launching with JDWP trace turned on (for example, java -Xrunjdwp:transport=dt_socket,suspend=n,server=y,trace=all HelloWorld) the trace output contains garbled content:
> 12:49:.625 FUNC: [PacketDispatcher.cpp:229] >> Clean(22DE7AE8)
> 12:49:.625 PROG: [PacketDispatcher.cpp:231] Clean: clean internal data
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D60520
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D60590
> 12:49:?12:49:.625 FUNC: [ThreadManager.cpp:202] >> Clean(22DE7AE8)
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D43108
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D43980
> 12:49:?12:49:.625 FUNC: [RequestManager.cpp:57] >> Clean(22DE7AE8)
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D435A8
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D43598
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 22D435B8
> 12:49:?12:49:?12:49:?12:49:?12:49:?12:49:e: 22DVM free: 22D61FA8.625 MEM: [Age
> ntBase.h:316] VM free: 22D61FA8
> 12:49:e: 22DVM free: 22D430E8.625 MEM: [AgentBase.h:316] VM free: 22D430E8
> 12:49:e: 22DVM free: 22D61FD8.625 MEM: [AgentBase.h:316] VM free: 22D61FD8
> 12:49:?12:49:912:49:‼.625 FUNC: [ClassManager.cpp:112] << Clean()
> 12:49:e: 22D<< Clean().625 FUNC: [AgentManager.cpp:113] << Clean()
> 12:49: cleanVM free: 0048E500.625 MEM: [AgentBase.h:316] VM free: 0048E500
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 0047B070
> 12:49:.625 MEM: [AgentBase.h:316] VM free: 004974A8
> 12:49:‼.625 MEM: [AgentBase.h:316] VM free: 22D61190
> 12:49:‼.625 MEM: [TransportManager.cpp:69] VM free: 22D61320
> 12:49:‼.625 MEM: [TransportManager.cpp:38] VM free: 22DEEEB8
> 12:49:.625 MEM: [TransportManager.cpp:38] VM free: 22D437F0
> 12:49::49:.625 MEM: [TransportManager.cpp:38] VM free: 22D49200
> 12:49::49::4VM free: 22D61250.625 MEM: [TransportManager.cpp:38] VM free: 22D6
> 1250
> 12:49:2D6132VM free: 0047A958.625 MEM: [AgentBase.h:316] VM free: 0047A958
> 12:49:2D6132VM free: 00496740.625 MEM: [AgentBase.h:316] VM free: 00496740
> 12:49:2D6132VM free: 0047A0A8.625 MEM: [AgentBase.h:316] VM free: 0047A0A8
> 12:49:2D6132VM free: 0048E570.625 MEM: [AgentBase.h:316] VM free: 0048E570
> 12:49:2D6132VM free: 0047B048.625 MEM: [AgentBase.h:316] VM free: 0047B048
> 12:49:?12:49:?12:49: free:VM free: 00479EA0.625 MEM: [AgentBase.h:316] VM free
> : 00479EA0
> 12:49:e:VM fVM free: 00497530.625 MEM: [AgentBase.h:316] VM free: 00497530
> It looks like it is the timestamp parsing that is causing the problem, in particular the seconds part. If I change the timestamp %H:%M:%S to %H:%M then the output is as expected, so I think there is a bug in hystr_ftime() when parsing and replacing the %S token.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.