harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Deakin (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-6274) [jdwp][java6] Garbled output in JDWP trace
Date Fri, 17 Jul 2009 12:59:15 GMT
[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
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.

View raw message