Bug#661632: javahelper: jh_depends determines incorrect class version on sparc
Hi, On Mon, 12 Mar 2012 21:41:26 +0100, Niels Thykier wrote: On 2012-03-12 21:31, Niels Thykier wrote: hd -n 1 -s 7 -e '/1 %02d' Actually, make that hexdump -n 1 -s 7 -e '/1 %02d'. Apparently, hd and hexdump are not as interchangable as I thought. I can confirm that it works on sparc and i386. However, I would suggest to use this: hexdump -n 1 -s 7 -e '/1 %u' In contrast to hd, I do not see a difference when specifying the field width 02 here. Using %u instead of %d will work with values 127. %d is signed and will print negative values if the class version is 127. But since we are far away from that anyway, it is probably a matter of taste. For now both versions produce the right result. ~Niels Best regards Kai __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#661632: javahelper: jh_depends determines incorrect class version on sparc
On 2012-02-28 19:08, Kai Ruschenburg wrote: Package: javahelper Version: 0.32 Severity: normal Tags: patch Hi, Hi, Thanks for the report. when packaging Java programs on sparc (using the sources fetched by apt-get source), on some programs (e.g. sat4j) this warning is printed: $ debuild [...] jh_depends -i Warning: Class version too new to recognise (88), might not run with any JVMs [...] This is caused by hd in the function getclassversion() in jh_depends. The output of hd seems to depend on the endianness of the architecture. Therefore probably not only sparc, but all big-endian architectures are affected. Changing line 37 from new=`hd -s 7 -n 1 -d $i | sed -n '2s/.*\([^ ][^ ]\) *$/\1/p'` to new=`hexdump -s 6 -n 2 -e '/1 %u ' -e '/2 r 256 * + p' $i | dc` should fix this. To be honest, I do not see why the old code should fail. The specification says that bytes 6 and 7 are read as an unsigned short in big-endian. Sure, our code fails if the class version suddenly jumps above 255 (because we only read the last byte). However, we are at 51 with Java7 so I do not see that coming anytime soon. Can you give me a hexdump of the 16 characters of the class file? Some examples: $ [...] Best regards Kai [...] ~Niels __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#661632: javahelper: jh_depends determines incorrect class version on sparc
Hi, On Mon, 12 Mar 2012 09:26:06 +0100, Niels Thykier wrote: On 2012-02-28 19:08, Kai Ruschenburg wrote: [...] Changing line 37 from new=`hd -s 7 -n 1 -d $i | sed -n '2s/.*\([^ ][^ ]\) *$/\1/p'` to new=`hexdump -s 6 -n 2 -e '/1 %u ' -e '/2 r 256 * + p' $i | dc` should fix this. To be honest, I do not see why the old code should fail. The specification says that bytes 6 and 7 are read as an unsigned short in big-endian. Sure, our code fails if the class version suddenly jumps above 255 (because we only read the last byte). However, we are at 51 with Java7 so I do not see that coming anytime soon. Right, as long as the class version fits into one byte, reading byte 7 is sufficient. But this is not the problem. The problem is hexdump's -d option, which (according to man hd) produces a zero-filled *two-byte* decimal display. So even if you do not read byte 6 (which for now is zero anyway), the output of hd -s 7 -n 1 -d is byte 7 filled with zeros to make it two-byte wide. This two-byte representation is differing on sparc compared to i386. Can you give me a hexdump of the 16 characters of the class file? This is not a problem of the class file. You can reproduce it with any class file. Here are the first 16 bytes of the file I used as an example in my report (compiled for Java 1.4): $ hd -n 16 Test.class ca fe ba be 00 00 00 30 00 0f 0a 00 03 00 0c 07 |...0| 0010 This is on sparc: $ hd -s 7 -n 1 -d Test.class 0007 30|0| 007 12288 008 This is on i386 (same class file): $ hd -s 7 -n 1 -d Test.class 0007 30|0| 007 00048 008 As you can see, on sparc the decimal representation of 0x3000 is printed, whereas on i386 it is the decimal representation of 0x0030. Please excuse that this was not clear in my initial report. [...] ~Niels Best regards Kai __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#661632: javahelper: jh_depends determines incorrect class version on sparc
On 2012-03-12 19:11, Kai Ruschenburg wrote: Hi, On Mon, 12 Mar 2012 09:26:06 +0100, Niels Thykier wrote: On 2012-02-28 19:08, Kai Ruschenburg wrote: [...] Changing line 37 from new=`hd -s 7 -n 1 -d $i | sed -n '2s/.*\([^ ][^ ]\) *$/\1/p'` to new=`hexdump -s 6 -n 2 -e '/1 %u ' -e '/2 r 256 * + p' $i | dc` should fix this. To be honest, I do not see why the old code should fail. The specification says that bytes 6 and 7 are read as an unsigned short in big-endian. Sure, our code fails if the class version suddenly jumps above 255 (because we only read the last byte). However, we are at 51 with Java7 so I do not see that coming anytime soon. Right, as long as the class version fits into one byte, reading byte 7 is sufficient. But this is not the problem. The problem is hexdump's -d option, which (according to man hd) produces a zero-filled *two-byte* decimal display. Right, I thought it only produced a single byte output. Assuming I got my hd-foo right, I believe: $ hd -n 1 -s 7 -e '/1 %02d' classfile would also produce the right result. If you can confirm this, I would like to use that instead (saves dependency for dc and it even simplier than the current code). So even if you do not read byte 6 (which for now is zero anyway), the output of hd -s 7 -n 1 -d is byte 7 filled with zeros to make it two-byte wide. This two-byte representation is differing on sparc compared to i386. Good old endian issues, I presume. [...] As you can see, on sparc the decimal representation of 0x3000 is printed, whereas on i386 it is the decimal representation of 0x0030. Please excuse that this was not clear in my initial report. That is quite all right. I had long forgotten hd did not output a single byte. :) [...] ~Niels Best regards Kai ~Niels __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#661632: javahelper: jh_depends determines incorrect class version on sparc
On 2012-03-12 21:31, Niels Thykier wrote: hd -n 1 -s 7 -e '/1 %02d' Actually, make that hexdump -n 1 -s 7 -e '/1 %02d'. Apparently, hd and hexdump are not as interchangable as I thought. ~Niels __ This is the maintainer address of Debian's Java team http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#661632: javahelper: jh_depends determines incorrect class version on sparc
Package: javahelper
Version: 0.32
Severity: normal
Tags: patch
Hi,
when packaging Java programs on sparc (using the sources fetched by apt-get
source), on some programs (e.g. sat4j) this warning is printed:
$ debuild
[...]
jh_depends -i
Warning: Class version too new to recognise (88), might not run with any JVMs
[...]
This is caused by hd in the function getclassversion() in jh_depends.
The output of hd seems to depend on the endianness of the architecture.
Therefore probably not only sparc, but all big-endian architectures are
affected.
Changing line 37 from
new=`hd -s 7 -n 1 -d $i | sed -n '2s/.*\([^ ][^ ]\) *$/\1/p'`
to
new=`hexdump -s 6 -n 2 -e '/1 %u ' -e '/2 r 256 * + p' $i | dc`
should fix this.
Some examples:
$ cat Test.java
public class Test {
public static void main(String[] args) {
}
}
$ javac -source 1.3 -target 1.3 Test.java
$ hd -s 7 -n 1 -d Test.class | sed -n '2s/.*\([^ ][^ ]\) *$/\1/p'
32
$ hexdump -s 6 -n 2 -e '/1 %u ' -e '/2 r 256 * + p' Test.class | dc
47
$ javac -source 1.4 -target 1.4 Test.java
$ hd -s 7 -n 1 -d Test.class | sed -n '2s/.*\([^ ][^ ]\) *$/\1/p'
88
$ hexdump -s 6 -n 2 -e '/1 %u ' -e '/2 r 256 * + p' Test.class | dc
48
$ javac -source 1.5 -target 1.5 Test.java
$ hd -s 7 -n 1 -d Test.class | sed -n '2s/.*\([^ ][^ ]\) *$/\1/p'
44
$ hexdump -s 6 -n 2 -e '/1 %u ' -e '/2 r 256 * + p' Test.class | dc
49
$ javac -source 1.6 -target 1.6 Test.java
$ hd -s 7 -n 1 -d Test.class | sed -n '2s/.*\([^ ][^ ]\) *$/\1/p'
00
$ hexdump -s 6 -n 2 -e '/1 %u ' -e '/2 r 256 * + p' Test.class | dc
50
Best regards
Kai
-- System Information:
Debian Release: 6.0.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: sparc (sparc64)
Kernel: Linux 2.6.32-5-sparc64-smp (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages javahelper depends on:
ii bsdmainutils8.0.13 collection of more utilities from
ii dctrl-tools 2.14.5 Command-line tools to process Debi
ii debhelper 8.0.0helper programs for debian/rules
ii devscripts 2.10.69+squeeze2 scripts to make the life of a Debi
ii dpkg-dev1.15.8.12Debian package development tools
ii fastjar 2:0.98-3 Jar creation utility
ii libarchive-zip-perl 1.30-3 Perl module for manipulation of ZI
javahelper recommends no packages.
Versions of packages javahelper suggests:
pn cvs none (no description available)
ii gawk 1:3.1.7.dfsg-5 GNU awk, a pattern scanning and pr
pn tofrodos none (no description available)
-- no debconf information
--- jh_depends.orig 2010-07-04 10:35:16.0 +0200
+++ jh_depends 2012-02-25 15:28:43.344986707 +0100
@@ -34,7 +34,7 @@
current=$1
classes=$2
for i in `find $classes -name *.class`; do
- new=`hd -s 7 -n 1 -d $i | sed -n '2s/.*\([^ ][^ ]\) *$/\1/p'`
+ new=`hexdump -s 6 -n 2 -e '/1 %u ' -e '/2 r 256 * + p'
$i | dc`
if (( $current $new )); then
current=$new
fi
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers.
Please use
debian-j...@lists.debian.org for discussions and questions.
