code swarm freezes processing RTEMS CVS repository

[GoogleCodeExporter]

I want to produce a video for the RTEMS Project (www.rtems.org).  We have 
about 15 years of CVS history so should be interesting to watch.

What steps will reproduce the problem?
1. CVS log dumped to activity.log
2. edited cvs log to get dates into yyyy-mm-dd since some were yyyy/mm/dd
3. ran converter ok

ran using sample config modified to use our xml output

Host: Fedora 10.

What is the expected output? What do you see instead?

It froze after about 20 seconds.  It popped up a window which never
got any test or graphics in it and quit using CPU time.

What version of the product are you using? On what operating system?

SVN revision 260

Please provide any additional information below.

I can provide the files but they are large.  I didn't want to dump them
into your issues system without permission.  Private email or ftp might be
best.

Do you want the raw cvs log? activity.xml?

Thanks. I would really like to see this run.

Original issue reported on code.google.com by joel.she...@gmail.com on 12 Mar 2009 at 8:53

[GoogleCodeExporter]

I'd like to see activity.xml.  If you need a place to put them, give me an 
email - rictic at gmail.

If your cvs log wasn't handled properly by the conversion tool, that's a bug as 
well.

Original comment by ric...@gmail.com on 13 Mar 2009 at 2:07

[GoogleCodeExporter]

Assuming that there's not an error, it's possible that code_swarm is using up 
all of your memory and your system 
is using all of its time swapping to the hard drive.

If it looks like this is the case, you might try out the experimental version 
here, which streams the xml file in 
rather than loading it all at once: http://github.com/rictic/code_swarm/ 

Original comment by ric...@gmail.com on 13 Mar 2009 at 2:34

[GoogleCodeExporter]

I have emailed rictic the raw log.  I ran this command in gvim and convert.py
can then process the file and produce an activity.xml

:g/[12][09][0-9][0-9]\/[0-9][0-9]\//s/\//-/g

I have attached "window.png" which is what the blank windows looks like when 
you 
do a screen capture on it like this:

 xwd | xwdtopnm | pnmtopng >/tmp/window.png

Not much to see. :)

The system monitor shows java is using 104.b MB RAM (I have 2 GB) and a 
dual-core
machine.  The "Waiting Channel" is futex_wait.  I checked it in top and this 
is what it showed:

23213 joel      20   0  210m 120m  14m S  0.0  6.0   0:40.5 java

So not much memory usage (6%) and it has quit using CPU.

Original comment by joel.she...@gmail.com on 13 Mar 2009 at 1:31

Attachments:

• window.png