Menu
▾
▴
tuningforkvp-issues — Mailing generated by tracker updates
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(22) |
Jul
(8) |
Aug
(9) |
Sep
(12) |
Oct
(23) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(6) |
Feb
(3) |
Mar
(10) |
Apr
(4) |
May
(4) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(4) |
Dec
(1) |
|
From: SourceForge.net <no...@so...> - 2009-12-28 18:36:31
|
Patches item #2922432, was opened at 2009-12-28 18:36 Message generated for change (Tracker Item Submitted) made by pfs-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066392&aid=2922432&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TF Core Platform Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter F. Sweeney (pfs-oss) Assigned to: Nobody/Anonymous (nobody) Summary: Convert seekToTime to binary search from linear Initial Comment: The seekToTime method was implemented as a linear search. This patch modifies the method to use a binary search to improve performance. This patch also contains the patch from 11/23/2009 that was submitted by Hai Chuan Wang to fix the hasMore() method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066392&aid=2922432&group_id=225876 |
|
From: Sripathi K. <sri...@in...> - 2009-11-23 10:31:14
|
On Fri, 20 Nov 2009 12:43:19 -0800 David P Grove <gr...@us...> wrote: Hi David, <snip> > > I haven't been able to reproduce this (but I'm on RHEL 5.4, 32 bit linux). > Everyone else on the TF team is either on Windows or Macs. My guess would > be that we have a race condition somewhere in TuningFork startup and by not > showing the intro you are somehow avoiding it. Any chance you still have > the javacore.txt file sitting around? That might have the stackdumps from > the various Java threads so we maybe could take a better guess at what is > happening. I can recreate the problem at will. I have attached a javacore I got today. I am pretty well versed with Linux, so I can help in debugging this from Linux side. However, my knowledge of Java is limited. The following is the backtrace I got from gdb: Core was generated by `./TuningFork'. Program terminated with signal 11, Segmentation fault. #0 0xf73fcc7d in j9dump_create () from /opt/ibm/java2-i386-50/jre/bin/libj9prt23.so (gdb) bt #0 0xf73fcc7d in j9dump_create () from /opt/ibm/java2-i386-50/jre/bin/libj9prt23.so #1 0xf737f078 in doSystemDump () from /opt/ibm/java2-i386-50/jre/bin/libj9dmp23.so #2 0xf7381654 in protectedDumpFunction () from /opt/ibm/java2-i386-50/jre/bin/libj9dmp23.so #3 0xf7404398 in j9sig_protect () from /opt/ibm/java2-i386-50/jre/bin/libj9prt23.so #4 0xf7381623 in runDumpFunction () from /opt/ibm/java2-i386-50/jre/bin/libj9dmp23.so #5 0xf7381509 in runDumpAgent () from /opt/ibm/java2-i386-50/jre/bin/libj9dmp23.so #6 0xf7384cac in triggerDumpAgents () from /opt/ibm/java2-i386-50/jre/bin/libj9dmp23.so #7 0xf74414f6 in dumpCrashData () from /opt/ibm/java2-i386-50/jre/bin/libj9vm23.so #8 0xf7404398 in j9sig_protect () from /opt/ibm/java2-i386-50/jre/bin/libj9prt23.so #9 0xf7440b7b in structuredSignalHandler () from /opt/ibm/java2-i386-50/jre/bin/libj9vm23.so #10 0xf7404aee in masterSynchSignalHandler () from /opt/ibm/java2-i386-50/jre/bin/libj9prt23.so #11 <signal handler called> #12 0xc5c0888d in gconv () from /usr/lib/gconv/UTF-16.so #13 0x00326597 in __gconv () from /lib/libc.so.6 #14 0x09bf9c98 in ?? () #15 0x09c07bb0 in ?? () #16 0xffc5ed14 in ?? () #17 0xd8e46db8 in ?? () #18 0x00000000 in ?? () Thanks, Sripathi. |
|
From: SourceForge.net <no...@so...> - 2009-11-23 06:58:39
|
Bugs item #2902296, was opened at 2009-11-23 01:58 Message generated for change (Tracker Item Submitted) made by wanghaic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2902296&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TF Core Platform Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hai Chuan Wang (wanghaic) Assigned to: Nobody/Anonymous (nobody) Summary: hasMore() return wrong value in FeedCursor class Initial Comment: The hasMore() method in com.ibm.tuningfork.infra.feed.FeedCursor has a bug logic. The current one is public boolean hasMore() { return (index > 0 && index < feed.numberOfEvents()) && beforeEndOfRange(feed.getEvent(index).getTime()); } It will return false in a new cursor since the new cursor's index == 0. For example in seekToTime() method public void seekToTime(long time) { index = (forward ? 0 : feed.numberOfEvents() - 1); while (hasMore()) { ... ... } } The index was assigned to 0 in forward mode, and the has to more will return false. The result is the cursor cannot seek to the right time. The fix should change "index > 0" to "index >= 0" in hasMore() method ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2902296&group_id=225876 |
|
From: David P G. <gr...@us...> - 2009-11-21 15:53:09
|
Sripathi Kodi <sri...@in...> wrote on 11/11/2009 02:59:41 AM: > > I posted this mail to tuningforkvp-users list, but I then saw that this > list is more active, so resending it here. Sorry about the cross-post. > I am a new member of these MLs. > Sorry to be so slow to respond. I didn't answer right away, then this got buried in my inbox. > > I am trying to use Tuningfork 2.0.0 on x86_64/Linux. Recently I noticed > that Tuningfork started crashing with a SEGV in one of system libraries > (libxul or UTF). It now happens every single time I try to start > TuningFork. However, I remembered that it had been working a few days > ago and I still had that directory intact. I started comparing the two > directories and narrowed down the problem to this: > > In the directory > Go to > $ cd tuningforkvp-2.0.0.linux.gtk.x86/tuningforkvp-2.0.0 > > Create this file to prevent the problem from happening: > > $ cat org.eclipse.ui.prefs > #Mon Nov 09 14:01:45 IST 2009 > eclipse.preferences.version=1 > showIntro=false > > Specifically, the line "showIntro=false" prevents the crash from > happening. > > Could anyone please tell me what this setting does and why is this > needed to prevent the crash from happening? > I haven't been able to reproduce this (but I'm on RHEL 5.4, 32 bit linux). Everyone else on the TF team is either on Windows or Macs. My guess would be that we have a race condition somewhere in TuningFork startup and by not showing the intro you are somehow avoiding it. Any chance you still have the javacore.txt file sitting around? That might have the stackdumps from the various Java threads so we maybe could take a better guess at what is happening. --dave |
|
From: Sripathi K. <sri...@in...> - 2009-11-11 11:00:01
|
Hi, I posted this mail to tuningforkvp-users list, but I then saw that this list is more active, so resending it here. Sorry about the cross-post. I am a new member of these MLs. I am trying to use Tuningfork 2.0.0 on x86_64/Linux. Recently I noticed that Tuningfork started crashing with a SEGV in one of system libraries (libxul or UTF). It now happens every single time I try to start TuningFork. However, I remembered that it had been working a few days ago and I still had that directory intact. I started comparing the two directories and narrowed down the problem to this: In the directory Go to $ cd tuningforkvp-2.0.0.linux.gtk.x86/tuningforkvp-2.0.0 Create this file to prevent the problem from happening: $ cat org.eclipse.ui.prefs #Mon Nov 09 14:01:45 IST 2009 eclipse.preferences.version=1 showIntro=false Specifically, the line "showIntro=false" prevents the crash from happening. Could anyone please tell me what this setting does and why is this needed to prevent the crash from happening? Java version: java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20090707 (SR10 )) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20090707 (JIT enabled) J9VM - 20090706_38445_lHdSMr JIT - 20090623_1334_r8 GC - 200906_09) JCL - 20090705 A typical console log when the crash happens: There are 0 temp files in the cache directory. Deleted 0 old temp files in the cache directory. Using direct invoke of paint from refresh loop workaround for Linux Unhandled exception Type=Segmentation error vmState=0x00040000 J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000002 Handler1=F7C78AE7 Handler2=F7C3C9F7 InaccessibleAddress=C5FFD000 EDI=C5FFD002 ESI=0B1F8848 EAX=0B1F884C EBX=C5FE9FF4 ECX=C5FFD000 EDX=00000000 EIP=C5FE788D ES=002B DS=002B ESP=FFFACC1C EFlags=00210287 CS=0023 SS=002B EBP=FFFACCE8 Module=/usr/lib/gconv/UTF-16.so Module_base_address=C5FE7000 Symbol=gconv Symbol_address=C5FE7690 Target=2_30_20090706_38445_lHdSMr (Linux 2.6.31-rc5.3.el5rt) CPU=x86 (4 logical CPUs) (0x1ec38b000 RAM) JVMDUMP006I Processing dump event "gpf", detail "" - please wait. JVMDUMP032I JVM requested System dump using '/data/sripathi/tuningfork/tuningforkvp-2.0.0.linux.gtk.x86/tuningforkvp-2.0.0/core.20091111.151000.8789.0001.dmp' in response to an event JVMDUMP010I System dump written to /data/sripathi/tuningfork/tuningforkvp-2.0.0.linux.gtk.x86/tuningforkvp-2.0.0/core.20091111.151000.8789.0001.dmp JVMDUMP032I JVM requested Snap dump using '/data/sripathi/tuningfork/tuningforkvp-2.0.0.linux.gtk.x86/tuningforkvp-2.0.0/Snap.20091111.151000.8789.0002.trc' in response to an event JVMDUMP010I Snap dump written to /data/sripathi/tuningfork/tuningforkvp-2.0.0.linux.gtk.x86/tuningforkvp-2.0.0/Snap.20091111.151000.8789.0002.trc JVMDUMP032I JVM requested Java dump using '/data/sripathi/tuningfork/tuningforkvp-2.0.0.linux.gtk.x86/tuningforkvp-2.0.0/javacore.20091111.151000.8789.0003.txt' in response to an event JVMDUMP010I Java dump written to /data/sripathi/tuningfork/tuningforkvp-2.0.0.linux.gtk.x86/tuningforkvp-2.0.0/javacore.20091111.151000.8789.0003.txt JVMDUMP013I Processed dump event "gpf", detail "". [root@llm50 tuningforkvp-2.0.0]# Thanks, Sripathi. |
|
From: SourceForge.net <no...@so...> - 2009-08-07 19:50:15
|
Feature Requests item #2833895, was opened at 2009-08-07 14:50 Message generated for change (Tracker Item Submitted) made by dgrove-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2833895&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TraceGen Library Group: None Status: Open Resolution: None Priority: 2 Private: No Submitted By: Dave Grove (dgrove-oss) Assigned to: Nobody/Anonymous (nobody) Summary: C++ trace gen library leaks feedlets Initial Comment: The C++ trace gen library has API for creating feedlets, but doesn't support removing feedlets from a Logger. This can cause resource exhaustion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2833895&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-06-04 03:43:00
|
Bugs item #2800873, was opened at 2009-06-03 23:42 Message generated for change (Tracker Item Submitted) made by wanghaic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2800873&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TF Core Platform Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Hai Chuan Wang (wanghaic) Assigned to: Nobody/Anonymous (nobody) Summary: BaseTimeIntervalStream not use the last event for summary Initial Comment: In BaseTimeIntervalStream, it override close(String info) for process the last time interval event. protected void close(String info) { if (!isClosed() && lastSeenEvent != null) { AbstractTimeInterval timeInterval = filter.close(lastSeenEvent.getTime()); addInterval(timeInterval); } super.close(info); } However, close(info) method is invocated after super class TimeIntervalStream's close() method protected void close() { for (int i = 0; i < curSummaries.length; i++) { if (curSummaries[i] != null) { summaries[i].add(curSummaries[i]); curSummaries[i] = null; } } super.close(persistedEventData, summaries); } This sequence will cause the final timeinterval event will not be used to generate the summary stream. If the precise stream only contains one time interval event, and the time interval event is generated in close method, this stream's summary will contain nothing, which will cause timeSeries figure cannot display it correctly. One possible fix method is in BaseTimeIntervalStream, it not override close(String info) , but override close() method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2800873&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-05-11 14:30:42
|
Bugs item #2779201, was opened at 2009-04-23 00:46 Message generated for change (Comment added) made by jsauerbach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2779201&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TraceGen Library Group: None >Status: Closed Resolution: None Priority: 7 Private: No Submitted By: Hai Chuan Wang (wanghaic) Assigned to: Joshua Auerbach (jsauerbach) Summary: JavaTraceGenerationLibrary generates bad format traces Initial Comment: JavaTraceGenerationLibrary has a bug in com.ibm.tuningfork.tracegen.impl.Logger.java, which may cause generates a bad format trace. It happens when there are a lot of environment properties, and one property chunk cannot contain them. Then the first property chunk will call flush(), and it will be put into closedMetaChunks. In method private synchronized void flush(boolean shutdown) there is if (os != null) { ListIterator chunkIterator = closedMetaChunks.listIterator(); while (chunkIterator.hasNext()) { RawChunk chunk = (RawChunk) chunkIterator.next(); chunk.write(os); } } And the first property chunk will be written into file. However, at this time, the header chunks in oldMetaChunks are not written to trace file yet. And when the method writeOldMetaChunks is invocated, the header chunks and the property chunk will be written, which causes bad format trace. One solution to it is to add a flag isHeaderChunksWritten to prevent writting property chunks before writting header chunks. ---------------------------------------------------------------------- >Comment By: Joshua Auerbach (jsauerbach) Date: 2009-05-11 10:30 Message: Checked in the suggested fix, which appears to work. ---------------------------------------------------------------------- Comment By: Joshua Auerbach (jsauerbach) Date: 2009-05-11 10:23 Message: The solution suggested by Hai Chuan appears to work and this bug is definitely cropping up sometimes simply due to randomly occuring larger-than-usual environments or property sets. So, I am testing the fix a bit more and will then commit it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2779201&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-05-11 14:28:00
|
Bugs item #2790106, was opened at 2009-05-11 10:25 Message generated for change (Comment added) made by jsauerbach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2790106&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Joshua Auerbach (jsauerbach) Assigned to: Joshua Auerbach (jsauerbach) Summary: Error when string and doubles both appear in an event type Initial Comment: The logic in EventParser.readEventSpecial is flawed for the case where there is a string attribute and also one or more double attributes. Logic incorrectly falls through to the assumption that there are no strings. The event is then parsed ignoring the string and so the next parse fails since the chunk cursor is incorrectly positioned. ---------------------------------------------------------------------- >Comment By: Joshua Auerbach (jsauerbach) Date: 2009-05-11 10:27 Message: Checked in fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2790106&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-05-11 14:25:45
|
Bugs item #2790106, was opened at 2009-05-11 10:25 Message generated for change (Tracker Item Submitted) made by jsauerbach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2790106&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joshua Auerbach (jsauerbach) Assigned to: Joshua Auerbach (jsauerbach) Summary: Error when string and doubles both appear in an event type Initial Comment: The logic in EventParser.readEventSpecial is flawed for the case where there is a string attribute and also one or more double attributes. Logic incorrectly falls through to the assumption that there are no strings. The event is then parsed ignoring the string and so the next parse fails since the chunk cursor is incorrectly positioned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2790106&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-05-11 14:23:12
|
Bugs item #2779201, was opened at 2009-04-23 00:46 Message generated for change (Comment added) made by jsauerbach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2779201&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TraceGen Library Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Hai Chuan Wang (wanghaic) >Assigned to: Joshua Auerbach (jsauerbach) Summary: JavaTraceGenerationLibrary generates bad format traces Initial Comment: JavaTraceGenerationLibrary has a bug in com.ibm.tuningfork.tracegen.impl.Logger.java, which may cause generates a bad format trace. It happens when there are a lot of environment properties, and one property chunk cannot contain them. Then the first property chunk will call flush(), and it will be put into closedMetaChunks. In method private synchronized void flush(boolean shutdown) there is if (os != null) { ListIterator chunkIterator = closedMetaChunks.listIterator(); while (chunkIterator.hasNext()) { RawChunk chunk = (RawChunk) chunkIterator.next(); chunk.write(os); } } And the first property chunk will be written into file. However, at this time, the header chunks in oldMetaChunks are not written to trace file yet. And when the method writeOldMetaChunks is invocated, the header chunks and the property chunk will be written, which causes bad format trace. One solution to it is to add a flag isHeaderChunksWritten to prevent writting property chunks before writting header chunks. ---------------------------------------------------------------------- >Comment By: Joshua Auerbach (jsauerbach) Date: 2009-05-11 10:23 Message: The solution suggested by Hai Chuan appears to work and this bug is definitely cropping up sometimes simply due to randomly occuring larger-than-usual environments or property sets. So, I am testing the fix a bit more and will then commit it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2779201&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-04-24 10:20:54
|
Feature Requests item #2743081, was opened at 2009-04-08 01:59 Message generated for change (Settings changed) made by wanghaic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2743081&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TF Core Platform Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Hai Chuan Wang (wanghaic) Assigned to: Nobody/Anonymous (nobody) Summary: Support loading feed with hundreds of feedlets Initial Comment: In current TF trace loading, each new feedlet will create EventChunkPool with 10 chunks, private final EventChunkPool allEventChunks = new EventChunkPool(2 * CHUNKS_PER_FEEDLET); And each chunk will preserve 128K memory. Because of this, TF will throw out of memory when loading trace with hundreds of feedlets, even if the trace is only 10MB in size. It's better if the pre-preserved memory could be smaller, and increased on-demand. ---------------------------------------------------------------------- Comment By: Hai Chuan Wang (wanghaic) Date: 2009-04-24 06:20 Message: I found an flag that can turn off pre-allocate feedlet chunks, and use dynamical allocation. When it is set to false, I can open trace with hundreds feedlets. Plug in com.ibm.tuningfork.infra, class com.ibm.tuningfork.infra.feed.EventChunkPool line 27 public static final boolean ALLOCATE_INSTEAD_OF_POOLING = true; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2743081&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-04-24 10:20:39
|
Feature Requests item #2743081, was opened at 2009-04-08 01:59 Message generated for change (Comment added) made by wanghaic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2743081&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TF Core Platform Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hai Chuan Wang (wanghaic) Assigned to: Nobody/Anonymous (nobody) Summary: Support loading feed with hundreds of feedlets Initial Comment: In current TF trace loading, each new feedlet will create EventChunkPool with 10 chunks, private final EventChunkPool allEventChunks = new EventChunkPool(2 * CHUNKS_PER_FEEDLET); And each chunk will preserve 128K memory. Because of this, TF will throw out of memory when loading trace with hundreds of feedlets, even if the trace is only 10MB in size. It's better if the pre-preserved memory could be smaller, and increased on-demand. ---------------------------------------------------------------------- >Comment By: Hai Chuan Wang (wanghaic) Date: 2009-04-24 06:20 Message: I found an flag that can turn off pre-allocate feedlet chunks, and use dynamical allocation. When it is set to false, I can open trace with hundreds feedlets. Plug in com.ibm.tuningfork.infra, class com.ibm.tuningfork.infra.feed.EventChunkPool line 27 public static final boolean ALLOCATE_INSTEAD_OF_POOLING = true; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2743081&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-04-23 04:46:33
|
Bugs item #2779201, was opened at 2009-04-23 00:46 Message generated for change (Tracker Item Submitted) made by wanghaic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2779201&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TraceGen Library Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: Hai Chuan Wang (wanghaic) Assigned to: Nobody/Anonymous (nobody) Summary: JavaTraceGenerationLibrary generates bad format traces Initial Comment: JavaTraceGenerationLibrary has a bug in com.ibm.tuningfork.tracegen.impl.Logger.java, which may cause generates a bad format trace. It happens when there are a lot of environment properties, and one property chunk cannot contain them. Then the first property chunk will call flush(), and it will be put into closedMetaChunks. In method private synchronized void flush(boolean shutdown) there is if (os != null) { ListIterator chunkIterator = closedMetaChunks.listIterator(); while (chunkIterator.hasNext()) { RawChunk chunk = (RawChunk) chunkIterator.next(); chunk.write(os); } } And the first property chunk will be written into file. However, at this time, the header chunks in oldMetaChunks are not written to trace file yet. And when the method writeOldMetaChunks is invocated, the header chunks and the property chunk will be written, which causes bad format trace. One solution to it is to add a flag isHeaderChunksWritten to prevent writting property chunks before writting header chunks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2779201&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-04-08 05:59:15
|
Feature Requests item #2743081, was opened at 2009-04-08 01:59 Message generated for change (Tracker Item Submitted) made by wanghaic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2743081&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TF Core Platform Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hai Chuan Wang (wanghaic) Assigned to: Nobody/Anonymous (nobody) Summary: Support loading feed with hundreds of feedlets Initial Comment: In current TF trace loading, each new feedlet will create EventChunkPool with 10 chunks, private final EventChunkPool allEventChunks = new EventChunkPool(2 * CHUNKS_PER_FEEDLET); And each chunk will preserve 128K memory. Because of this, TF will throw out of memory when loading trace with hundreds of feedlets, even if the trace is only 10MB in size. It's better if the pre-preserved memory could be smaller, and increased on-demand. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2743081&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-03-18 18:49:32
|
Feature Requests item #2653312, was opened at 2009-03-01 20:53 Message generated for change (Settings changed) made by dgrove-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2653312&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TF Core Platform Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hai Chuan Wang (wanghaic) >Assigned to: David F. Bacon (dfbacon) Summary: Derive stream from two or more feeds Initial Comment: The interface definition of a filter supports more than one data source, which means two feeds can be accepted and derived to a stream. However, although I can create a filter and input two feeds as IDataSource[], it seems it always uses only the first feed to derive the stream. I checked the code of Stream.class, and find code public Stream(String name, IDataSource[] dataSource, Unit unit, EventType type) { // FIXME: seems to only work with one Feed input, but interface allows multiple this.streamMode = StreamMode.DERIVED_FROM_FEED; this.timeConverter = dataSource[0].getTimeConverter(); if (!Filter.checkConsistency(dataSource)) { Logging.errorln("Creation of stream with inconsistent time converters"); } this.dataSources = dataSource; this.operator = new Operator("Base"); this.operands = StreamOperand.EMPTY; this.canonicalName = "Base("; for (IDataSource source: dataSource) { long id = source.getCanonicalId(); this.canonicalName += (id + ","); } this.canonicalName += name + ")"; this.eventType = type; commonInit(name, dataSource, unit); } protected void derivedFromFeedRun() { // FIXME: constructors seem to allow multiple Feeds from which to derive IFeeder source = (IFeeder) dataSources[0]; while (true) { TypedEvent e = source.getEvent(cursors[0]); if (e != null) { cursors[0]++; addEvent(e); lastSeenEvent = e; modify(); } else if (source.isClosed()) { if (cursors[0] >= source.numberOfEvents()) { break; } else { Logging.errorln("missing event " + cursors[0] + " from feed"); break; } } else { modifyCheck(); MiscUtils.milliSleep(100); } } } It only uses the first feed to derive a stream. Can we derive a stream from two feeds? Or are there any alternatives that can support the similar features in current TuningFork release? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2653312&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-03-18 18:48:14
|
Feature Requests item #2035253, was opened at 2008-08-01 15:29 Message generated for change (Settings changed) made by dgrove-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2035253&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TF Core Platform Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: David F. Bacon (dfbacon) >Assigned to: Nobody/Anonymous (nobody) Summary: Incremental summarization streams Initial Comment: Provide a transparent mechanism for avoiding storage of every event in a SummarizingEventStream -- instead keep only a subset and have the cursor objects dynamically recompute by interpolating with the summarization function. ---------------------------------------------------------------------- Comment By: Dave Grove (dgrove-oss) Date: 2008-10-15 12:35 Message: Done? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2035253&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-03-18 18:48:02
|
Feature Requests item #2042078, was opened at 2008-08-07 14:37 Message generated for change (Settings changed) made by dgrove-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2042078&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TF Core Platform Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: David F. Bacon (dfbacon) >Assigned to: Nobody/Anonymous (nobody) Summary: End time chunk Initial Comment: Put chunk which provide the last time in the feed at the end of the file in a way that is parsabe in reverse; this will allow us to put the feed into the right feedgroup quickly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2042078&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-03-18 18:48:02
|
Feature Requests item #2035249, was opened at 2008-08-01 15:26 Message generated for change (Settings changed) made by dgrove-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2035249&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TF Core Platform Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: David F. Bacon (dfbacon) >Assigned to: Nobody/Anonymous (nobody) Summary: Splash screen alternate personality Initial Comment: For tools that are significant extensions to TuningFork that wish to have their own "major" identity, rather than the "minor" identity of the small icons from feature plugins, create a standard splash screen layout with a small TuningFork branding at the bottom and a larger area into which they can put a JPG splash image. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2035249&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-03-18 18:47:29
|
Feature Requests item #2035247, was opened at 2008-08-01 15:24 Message generated for change (Settings changed) made by dgrove-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2035247&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TF Core Platform Group: None Status: Open Resolution: None Priority: 4 Private: No Submitted By: David F. Bacon (dfbacon) >Assigned to: Nobody/Anonymous (nobody) Summary: Sample painter draw mode: fill below curve Initial Comment: Will allow time series to display stacked curves, although assuming the user computes the "stacked" sample stream. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2035247&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-03-18 18:47:18
|
Feature Requests item #2042067, was opened at 2008-08-07 14:30 Message generated for change (Settings changed) made by dgrove-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2042067&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: David F. Bacon (dfbacon) Assigned to: Philippe Charles (pgcharles) Summary: Migrate from use of TimedRelation to IEvents w/relations Initial Comment: Use events containing relations instead of the specialized TimedRelation and RelationStream types, which have been deprecated. Then kill them. ---------------------------------------------------------------------- Comment By: Dave Grove (dgrove-oss) Date: 2008-10-15 12:35 Message: I think this is complete. Can we close? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2042067&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-03-18 18:47:08
|
Feature Requests item #2035266, was opened at 2008-08-01 15:40 Message generated for change (Settings changed) made by dgrove-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2035266&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TF Core Platform Group: None Status: Open Resolution: None Priority: 7 Private: No Submitted By: David F. Bacon (dfbacon) >Assigned to: Nobody/Anonymous (nobody) Summary: Manage CacheArray consumption Initial Comment: CacheArrays consume a lot of memory. Right now they are statically sized. They should instead size themselves dynamically, getting smaller as the number of them increases, and getting smaller as they become less recently used. ---------------------------------------------------------------------- Comment By: David F. Bacon (dfbacon) Date: 2008-08-07 14:57 Message: Logged In: YES user_id=1214585 Originator: YES Refinements: 1. use meta-LRU on the cache arrays themselves,giving more cache space to more recently active arrays. 2. find actual size of objects the arrays refer to, not just the number of entries. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2035266&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-03-18 18:41:48
|
Bugs item #2681155, was opened at 2009-03-10 21:56 Message generated for change (Comment added) made by dgrove-oss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2681155&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TF Core Platform Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hai Chuan Wang (wanghaic) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in PlayerController(No detach of figure' player) Initial Comment: Each time a figure is created, the figure's player will be attached to FeedGroup's playercontroller. Plugin com.ibm.tuningfork.core Class com.ibm.tuningfork.core.player.Player Method public void attach(PlayerController controller) However, when a user closes the figure, there is no any detach method invocation, and the PlayerController will still maintain the links to the player, and causes memory leak. Although there is a detach method, this method is only invocated by button action. ---------------------------------------------------------------------- >Comment By: Dave Grove (dgrove-oss) Date: 2009-03-18 13:41 Message: This is definitely a leak, but is just one of many places where we are holding onto pointers to objects that belong to closed figures. Resource management is definitely something that has lots of holes in the current system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2681155&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-03-11 02:58:15
|
Bugs item #2681155, was opened at 2009-03-10 22:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2681155&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TF Core Platform Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hai Chuan Wang (wanghaic) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in PlayerController(No detach of figure' player) Initial Comment: Each time a figure is created, the figure's player will be attached to FeedGroup's playercontroller. Plugin com.ibm.tuningfork.core Class com.ibm.tuningfork.core.player.Player Method public void attach(PlayerController controller) However, when a user closes the figure, there is no any detach method invocation, and the PlayerController will still maintain the links to the player, and causes memory leak. Although there is a detach method, this method is only invocated by button action. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066390&aid=2681155&group_id=225876 |
|
From: SourceForge.net <no...@so...> - 2009-03-02 01:53:32
|
Feature Requests item #2653312, was opened at 2009-03-01 20:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2653312&group_id=225876 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: TF Core Platform Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hai Chuan Wang (wanghaic) Assigned to: Nobody/Anonymous (nobody) Summary: Derive stream from two or more feeds Initial Comment: The interface definition of a filter supports more than one data source, which means two feeds can be accepted and derived to a stream. However, although I can create a filter and input two feeds as IDataSource[], it seems it always uses only the first feed to derive the stream. I checked the code of Stream.class, and find code public Stream(String name, IDataSource[] dataSource, Unit unit, EventType type) { // FIXME: seems to only work with one Feed input, but interface allows multiple this.streamMode = StreamMode.DERIVED_FROM_FEED; this.timeConverter = dataSource[0].getTimeConverter(); if (!Filter.checkConsistency(dataSource)) { Logging.errorln("Creation of stream with inconsistent time converters"); } this.dataSources = dataSource; this.operator = new Operator("Base"); this.operands = StreamOperand.EMPTY; this.canonicalName = "Base("; for (IDataSource source: dataSource) { long id = source.getCanonicalId(); this.canonicalName += (id + ","); } this.canonicalName += name + ")"; this.eventType = type; commonInit(name, dataSource, unit); } protected void derivedFromFeedRun() { // FIXME: constructors seem to allow multiple Feeds from which to derive IFeeder source = (IFeeder) dataSources[0]; while (true) { TypedEvent e = source.getEvent(cursors[0]); if (e != null) { cursors[0]++; addEvent(e); lastSeenEvent = e; modify(); } else if (source.isClosed()) { if (cursors[0] >= source.numberOfEvents()) { break; } else { Logging.errorln("missing event " + cursors[0] + " from feed"); break; } } else { modifyCheck(); MiscUtils.milliSleep(100); } } } It only uses the first feed to derive a stream. Can we derive a stream from two feeds? Or are there any alternatives that can support the similar features in current TuningFork release? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1066393&aid=2653312&group_id=225876 |