public inbox for java-prs@sourceware.org help / color / mirror / Atom feed
From: "jrandom-gcc at i2p dot net" <gcc-bugzilla@gcc.gnu.org> To: java-prs@gcc.gnu.org Subject: [Bug java/24461] New: array access in either GZIPInputStream, Inflater, natInflate.cc, or zlib Date: Thu, 20 Oct 2005 19:48:00 -0000 [thread overview] Message-ID: <bug-24461-11561@http.gcc.gnu.org/bugzilla/> (raw) I hate posting bug reports without test cases, but this one is a bit beyond me - hopefully someone else will know whats up. Symptom: java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(java.lang.Object, int, java.lang.Object, int, int) (/usr/local/gcc-4.0.2/lib/libgcj.so.6.0.0) at java.util.zip.GZIPInputStream.read(byte[], int, int) (/usr/local/gcc-4.0.2/lib/libgcj.so.6.0.0) at java.io.FilterInputStream.read(byte[]) (/usr/local/gcc-4.0.2/lib/libgcj.so.6.0.0) at net.i2p.i2ptunnel.HTTPResponseOutputStream$Pusher.run() (/home/jrandom/dev/i2p/build/libi2p.so) at java.lang.Thread.run() (/usr/local/gcc-4.0.2/lib/libgcj.so.6.0.0) This occurs on EOF, the buffer passed in to GZIPInputStream is 8KB, and the length and offset fields are fine too (set by FilterInputStream as '0, buf.length'). The problem is, I believe, in the inf.getRemaining() and/or the fixed size buffer in GZIPInputStream: byte[] tmp = new byte[8]; // First copy remaining bytes from inflater input buffer. int avail = inf.getRemaining(); System.arraycopy(this.buf, this.len - avail, tmp, 0, avail); I have no idea why tmp is 8 bytes long, probably something I don't understand about zlib. inf.getRemaining() just returns 'z_streamp->avail_in', and from what I can see, that can either be set explicitly, via inflater.setInput(buf[], off, len), or implicitly, within zlib's inflate(z_streamp, Z_SYNC_FLUSH). My very cursory look into inflate(...) leads me nowhere, but InflaterInputStream.java seems to be allowing arbitrarily large setInput(buf, 0, buf.length) calls - e.g. line 157. The default buf.length is 4KB. Or, maybe is there something in the zlib format such that it will never have more than 8 bytes uninflated? FWIW, I'm on the latest zlib (1.2.3) and gcj 4.0.2 (and I haven't seen any updates on the related classes in gcj's cvsweb) =jr -- Summary: array access in either GZIPInputStream, Inflater, natInflate.cc, or zlib Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jrandom-gcc at i2p dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24461
next reply other threads:[~2005-10-20 19:48 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-10-20 19:48 jrandom-gcc at i2p dot net [this message] 2005-10-22 11:57 ` [Bug libgcj/24461] " jrandom-gcc at i2p dot net 2005-10-24 19:05 ` tromey at gcc dot gnu dot org 2005-10-24 19:31 ` tromey at gcc dot gnu dot org 2006-02-04 23:51 ` tromey at gcc dot gnu dot org 2006-03-09 19:02 ` tromey at gcc dot gnu dot org 2006-03-09 20:22 ` tromey at gcc dot gnu dot org 2006-03-09 20:25 ` tromey at gcc dot gnu dot org 2006-03-09 20:27 ` tromey at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-24461-11561@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=java-prs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).