Bug#478129: statsvn: java.lang.NullPointerException when used with Kaffe

Vincent Fourmond fourmond at debian.org
Sun Apr 27 16:21:38 UTC 2008


  Hello,

Ludovic Rousseau wrote:
> $ statsvn logfile.log .
> 27 avr. 08 13:51:13 net.sf.statsvn.util.JavaUtilTaskLogger info
> INFO: StatSVN - SVN statistics generation
> 
> java.lang.NullPointerException
>    at java.io.FilterInputStream.close (FilterInputStream.java:201)
>    at java.io.BufferedInputStream.close (BufferedInputStream.java:176)
>    at net.sf.statsvn.util.ProcessUtils.close (ProcessUtils.java:45)
>    at net.sf.statsvn.util.SvnStartupUtils.checkSvnVersionSufficient (SvnStartupUtils.java:81)
>    at net.sf.statsvn.Main.generate (Main.java:110)
>    at net.sf.statsvn.Main.main (Main.java:83)
> 
> 
> $ update-alternatives --display java
> java - status is manual.
>  link currently points to /etc/alternatives/kaffe-system/bin/java
> /usr/bin/gij-4.3 - priority 43
> /usr/lib/jvm/java-gcj/jre/bin/java - priority 1042
> /etc/alternatives/kaffe-system/bin/java - priority 300
>  slave java.1.gz: /usr/share/man/man1/java.kaffe.1.gz
> /usr/lib/jvm/java-1.5.0-sun/jre/bin/java - priority 53
>  slave java.1.gz: /usr/lib/jvm/java-1.5.0-sun/jre/man/man1/java.1.gz
> Current `best' version is /usr/lib/jvm/java-gcj/jre/bin/java.
> 
> 
> I first tried to use /usr/lib/jvm/java-gcj/jre/bin/java which is a link
> to /usr/bin/gij-4.3 but statsvn consume all my memory (RAM + swap) and
> does not finish. Log bellow:
> 
> $ statsvn logfile.log .
> 27-avr-08 9:04:00  net.sf.statsvn.util.JavaUtilTaskLogger info
> INFO: StatSVN - SVN statistics generation
> 
> Parsing SVN log 'logfile.log' exclude pattern 'null'
> Scheduled 0 svn diff calls on 0 threads.
> Generating report for /pcsclite/trunk/Drivers into 
> Using default CSS file (statcvs.css)
> writing chart 'Lines of Code and Churn Level' to locandchurn.png
> Creating CSS file at 'statcvs.css'
> writing chart 'Contributed Lines of Code' to loc_per_author.png
> writing chart 'Activity by Hour of Day' to activity_time.png
> writing chart 'Activity by Day of Week' to activity_day.png
> writing chart 'Commit Activity' to commitscatterauthors.png
> writing chart 'Author Activity' to activity.png
> writing chart 'Activity by Hour of Day for corcoran' to activity_time_corcoran.png
> writing chart 'Activity by Day of Week for corcoran' to activity_day_corcoran.png
> writing chart 'Activity of corcoran' to directory_sizes_corcoran.png
> Processus arrêté
> 
> 
> Using /usr/lib/jvm/java-1.5.0-sun/jre/bin/java (from sun-java5-jre) the
> execution is very fast and does not consume so much RAM.
> 
> I suggest you add a note in /usr/share/doc/statsvn/README.Debian that
> kaffe and gij are not good enough for statsvn.

  The problem is that I managed to run statsvn perfectly fine in a clean
sid chroot with only gij installed. However, for a reason which escapes
me, statsvn will apparently only work with sun's java if the latter is
installed. This is why the newer detection script (in NEW because it
seems it could move to main) puts first sun's java before other java
machines. I'm unsure I've tried with kaffe, in a clean chroot, though.

  However, I'm completely puzzled by why that happens. I think it is
related to bug #459281, but I'm quite unsure for now. I can't understand
what is the difference between both of my working machines (sid
main/contrib/nonfree with sun's java) and a clean sid (main) chroot, in
which I had no problems with statsvn so far.

  BTW: unless I'm mistaken, the wrapper scripts for now ignores java
alternatives unless it can't find the runtime the script is requiring.
Running this way:

DEBUG_WRAPPER=1 statsvn ...

would give information about which JVM is actually being used.

  Cheers,

	Vincent

-- 
Vincent Fourmond, Debian Developer
http://vince-debian.blogspot.com/
-- pretty boring signature, isn't it ?





More information about the pkg-java-maintainers mailing list