[jira] [Commented] (BCEL-303) AssertionViolatedException in Pass 3A Verification of invoke instructions

[Rohan Padhye (Jira)]

[ 
https://issues.apache.org/jira/browse/BCEL-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937872#comment-16937872
 ] 

Rohan Padhye commented on BCEL-303:
---

The class files attached with this bug report and similar ones that I submitted 
(BCEL-303, BCEL-307, BCEL-308, BCEL-309, BCEL-310, BCEL-311, BCEL-312, 
BCEL-313) are all automatically generated by a fuzzer. I do not have 
corresponding source to compile with package names. Do you know of a tool for 
editing the bytecode directly to add a package name? Thanks.

Otherwise, I would suggest not including all these test cases in the same 
classpath, but instead having the tests use a temporary class loader to load 
these package-less classes from a given directory.

> AssertionViolatedException in Pass 3A Verification of invoke instructions
> -
>
> Key: BCEL-303
> URL: https://issues.apache.org/jira/browse/BCEL-303
> Project: Commons BCEL
>  Issue Type: Bug
>  Components: Verifier
>Affects Versions: 6.2
>Reporter: Rohan Padhye
>Priority: Major
> Attachments: A.class
>
>
> The verifier throws an assertion violation / INTERNAL ERROR in pass 3A when 
> verifying a malformed class file.
> As I understand it, the issue is that if class A implements interface B, then 
> class A can be pass stage 1 verification even if class B is not resolved. 
> However, pass 3A verification of code that invokes a method defined on class 
> A assumes that the receiver type and all its interfaces are fully resolved.
> h1. Steps to reproduce:
>  
> Save the attached file as "example/A.class" and run:
> java -cp  org.apache.bcel.verifier.Verifier example.A
>  
> The file A.class was generated automatically by the fuzzer JQF 
> (https://github.com/rohanpadhye/jqf).
> h2. Expected output:
> VERIFIED_REJECTED
> h2. Observed output:
> JustIce by Enver Haase, (C) 2001-2002.
> 
> 
>  
> Now verifying: example.A
>  
> Pass 1:
> VERIFIED_OK
> Passed verification.
>  
> Pass 2:
> VERIFIED_OK
> Passed verification.
>  
> Exception in thread "main" 
> org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: 
> Missing class: java.lang.ClassNotFoundException: Exception while looking for 
> class example.I0: java.io.IOException: Couldn't find: example/I0.class
>  at 
> org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.visitINVOKEVIRTUAL(Pass3aVerifier.java:1315)
>  at org.apache.bcel.generic.INVOKEVIRTUAL.accept(INVOKEVIRTUAL.java:89)
>  at 
> org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:302)
>  at 
> org.apache.bcel.verifier.statics.Pass3aVerifier.pass3StaticInstructionOperandsChecks(Pass3aVerifier.java:443)
>  at 
> org.apache.bcel.verifier.statics.Pass3aVerifier.do_verify(Pass3aVerifier.java:208)
>  at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:71)
>  at org.apache.bcel.verifier.Verifier.doPass3a(Verifier.java:89)
>  at org.apache.bcel.verifier.Verifier.main(Verifier.java:216)
> Caused by: java.lang.ClassNotFoundException: Exception while looking for 
> class example.I0: java.io.IOException: Couldn't find: example/I0.class
>  at 
> org.apache.bcel.util.MemorySensitiveClassPathRepository.loadClass(MemorySensitiveClassPathRepository.java:97)
>  at org.apache.bcel.classfile.JavaClass.getInterfaces(JavaClass.java:847)
>  at 
> org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.getMethodRecursive(Pass3aVerifier.java:1181)
>  at 
> org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.visitINVOKEVIRTUAL(Pass3aVerifier.java:1304)
>  ... 7 more
> Caused by: java.io.IOException: Couldn't find: example/I0.class
>  at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:279)
>  at org.apache.bcel.util.ClassPath.getInputStream(ClassPath.java:209)
>  at org.apache.bcel.util.ClassPath.getInputStream(ClassPath.java:188)
>  at 
> org.apache.bcel.util.MemorySensitiveClassPathRepository.loadClass(MemorySensitiveClassPathRepository.java:95)
>  ... 10 more
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys

[Rohan Padhye (Jira)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937868#comment-16937868
 ] 

Rohan Padhye commented on COLLECTIONS-714:
--

If there is no fix, then silently failing (with only comments in the doc) does 
not seem like a great idea. The data structure is quite unstable if a 
previously inserted key disappears because another distinct key gets added. 
Also, this breaks the JDK Map contract since two non-equals() keys cannot be 
distinguished by two Map entries. If PatriciaTrie cannot support trailing null 
bytes in keys, it needs to throw an IllegalArgumentException or something in 
the put() method, constructor, and other places where new entries are created.

> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char) 
> is different from the string "x\u" (of length = 2 chars). However, 
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce: 
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1);   // key of length 2
> map.put("x\uy", 2);  // key of length 3
> Assert.assertEquals(3, map.size());  // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size());  // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and 
> "x\uy". The key "x" gets overwritten. Here is another way to repro the 
> bug: 
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key 
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings. 
> In general, I believe this also breaks the JDK Map contract since the keys 
> "x".equals("x\u") is false. 
> This bug was found automatically using JQF: 
> [https://github.com/rohanpadhye/jqf].
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys

[Rohan Padhye (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887759#comment-16887759
 ] 

Rohan Padhye commented on COLLECTIONS-714:
--

Started a PR: [https://github.com/apache/commons-collections/pull/78]

> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char) 
> is different from the string "x\u" (of length = 2 chars). However, 
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce: 
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1);   // key of length 2
> map.put("x\uy", 2);  // key of length 3
> Assert.assertEquals(3, map.size());  // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size());  // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and 
> "x\uy". The key "x" gets overwritten. Here is another way to repro the 
> bug: 
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key 
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings. 
> In general, I believe this also breaks the JDK Map contract since the keys 
> "x".equals("x\u") is false. 
> This bug was found automatically using JQF: 
> [https://github.com/rohanpadhye/jqf].
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys

[Rohan Padhye (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohan Padhye updated COLLECTIONS-714:
-
External issue URL: https://github.com/apache/commons-collections/pull/78

> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char) 
> is different from the string "x\u" (of length = 2 chars). However, 
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce: 
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1);   // key of length 2
> map.put("x\uy", 2);  // key of length 3
> Assert.assertEquals(3, map.size());  // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size());  // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and 
> "x\uy". The key "x" gets overwritten. Here is another way to repro the 
> bug: 
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key 
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings. 
> In general, I believe this also breaks the JDK Map contract since the keys 
> "x".equals("x\u") is false. 
> This bug was found automatically using JQF: 
> [https://github.com/rohanpadhye/jqf].
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Comment Edited] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys

[Rohan Padhye (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16831896#comment-16831896
 ] 

Rohan Padhye edited comment on COLLECTIONS-714 at 5/3/19 5:39 AM:
--

Upon further investigation I noticed that the problem lies in the way 
PatriciaTrie uses the results of StringKeyAnalyzer.

The insertion of entry with key "x\u" when key "x" already exists, hits 
this path in AbstractPatriciaTrie.put():
{code:java}
} else if (KeyAnalyzer.isEqualBitKey(bitIndex)) {
// This is a very special and rare case.

/* REPLACE OLD KEY+VALUE */
if (found != root) { // NOPMD
incrementModCount();
return found.setKeyValue(key, value);
}
}
{code}
 

I'm not sure what the "very special and rare case" is that the original 
developer intended, but it incorrectly overwrites the found key "x" with new 
key "x\u".

The above branch is executed because the call to 
AbstractPatriciaTrie.bitIndex("x", "x\u") returns EQUAL_BIT_KEY, which 
seems incorrect. The bug may be rooted in the way StringKeyAnalyzer.bitIndex() 
handles cases where index1 >= endIndex1: with the placeholder value `0`, which 
is actually a valid character in Java.

I cannot think of a simple fix at the top of my head, since the entire 
XOR-based algorithm seems to rely on the assumption that two non-equal keys 
must have a bit-index where their corresponding bits differ. This algorithm 
does not consider the fact that two keys can be non-equal simply because they 
have different lengths.


was (Author: rohanpadhye):
Upon further investigation I noticed that the problem lies in the way 
PatriciaTrie uses the results of StringKeyAnalyzer.

The insertion of entry with key "x\u" when key "x" already exists, hits 
this path in AbstractPatriciaTrie.put():
{code:java}
} else if (KeyAnalyzer.isEqualBitKey(bitIndex)) {
// This is a very special and rare case.

/* REPLACE OLD KEY+VALUE */
if (found != root) { // NOPMD
incrementModCount();
return found.setKeyValue(key, value);
}
}
{code}
 

I'm not sure what the "very special and rare case" is that the original 
developer intended, but it incorrectly overwrites the found key "x" with new 
key "x\u".

Why is the above branch executed? Because the call to 
AbstractPatriciaTrie.bitIndex("x", "x\u") returns EQUAL_BIT_KEY, which 
seems incorrect. The bug may be rooted in the way StringKeyAnalyzer.bitIndex() 
handles cases where index1 >= endIndex1: with the placeholder value "0", which 
is actually a valid character in Java.

I cannot think of a simple fix at the top of my head, since the entire 
XOR-based algorithm seems to rely on the assumption that two non-equal keys 
must have a bit-index where their corresponding bits differ. This algorithm 
does not consider the fact that two keys can be non-equal simply because they 
have different lengths.

> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char) 
> is different from the string "x\u" (of length = 2 chars). However, 
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce: 
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1);   // key of length 2
> map.put("x\uy", 2);  // key of length 3
> Assert.assertEquals(3, map.size());  // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size());  // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and 
> "x\uy". The key "x" gets overwritten. Here is another way to repro the 
> bug: 
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key 
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings. 
> In general, I believe this also breaks the JDK Map contract since the keys 
> "x".equals("x\u") is false. 
> This bug was found automatically using JQF: 
> [https://github.com/rohanpadhye/jqf].
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys

[Rohan Padhye (JIRA)]

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16831896#comment-16831896
 ] 

Rohan Padhye commented on COLLECTIONS-714:
--

Upon further investigation I noticed that the problem lies in the way 
PatriciaTrie uses the results of StringKeyAnalyzer.

The insertion of entry with key "x\u" when key "x" already exists, hits 
this path in AbstractPatriciaTrie.put():
{code:java}
} else if (KeyAnalyzer.isEqualBitKey(bitIndex)) {
// This is a very special and rare case.

/* REPLACE OLD KEY+VALUE */
if (found != root) { // NOPMD
incrementModCount();
return found.setKeyValue(key, value);
}
}
{code}
 

I'm not sure what the "very special and rare case" is that the original 
developer intended, but it incorrectly overwrites the found key "x" with new 
key "x\u".

Why is the above branch executed? Because the call to 
AbstractPatriciaTrie.bitIndex("x", "x\u") returns EQUAL_BIT_KEY, which 
seems incorrect. The bug may be rooted in the way StringKeyAnalyzer.bitIndex() 
handles cases where index1 >= endIndex1: with the placeholder value "0", which 
is actually a valid character in Java.

I cannot think of a simple fix at the top of my head, since the entire 
XOR-based algorithm seems to rely on the assumption that two non-equal keys 
must have a bit-index where their corresponding bits differ. This algorithm 
does not consider the fact that two keys can be non-equal simply because they 
have different lengths.

> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char) 
> is different from the string "x\u" (of length = 2 chars). However, 
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce: 
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1);   // key of length 2
> map.put("x\uy", 2);  // key of length 3
> Assert.assertEquals(3, map.size());  // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size());  // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and 
> "x\uy". The key "x" gets overwritten. Here is another way to repro the 
> bug: 
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key 
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings. 
> In general, I believe this also breaks the JDK Map contract since the keys 
> "x".equals("x\u") is false. 
> This bug was found automatically using JQF: 
> [https://github.com/rohanpadhye/jqf].
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys

[Rohan Padhye (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohan Padhye updated COLLECTIONS-714:
-
Description: 
In Java, strings are not null terminated. The string "x" (of length = 1 char) 
is different from the string "x\u" (of length = 2 chars). However, 
PatriciaTrie does not seem to distinguish between these strings.

To reproduce: 
{code:java}
public void testNullTerminatedKey1() {
Map map = new HashMap<>();
map.put("x", 0); // key of length 1
map.put("x\u", 1);   // key of length 2
map.put("x\uy", 2);  // key of length 3
Assert.assertEquals(3, map.size());  // ok, 3 distinct keys

PatriciaTrie trie = new PatriciaTrie<>(map);
Assert.assertEquals(3, trie.size());  // fail; actual=2
}{code}
In the above example, the resulting trie has only two keys: "x\u" and 
"x\uy". The key "x" gets overwritten. Here is another way to repro the bug: 
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.containsKey("x")); // fail
}
{code}
In the above example, the key "x" suddenly disappears when an entry with key 
"x\u" is inserted.

The PatriciaTrie docs do not mention anything about null-terminated strings. In 
general, I believe this also breaks the JDK Map contract since the keys 
"x".equals("x\u") is false. 

This bug was found automatically using JQF: 
[https://github.com/rohanpadhye/jqf].

 

  was:
In Java, strings are not null terminated. The string "x" (of length = 1 char) 
is different from the string "x\u" (of length = 2 chars). However, 
PatriciaTrie does not seem to distinguish between these strings.

To reproduce: 
{code:java}
public void testNullTerminatedKey1() {
Map map = new HashMap<>();
map.put("x", 0); // key of length 1
map.put("x\u", 1);   // key of length 2
map.put("x\uy", 2);  // key of length 3
Assert.assertEquals(3, map.size());  // ok, 3 distinct keys

PatriciaTrie trie = new PatriciaTrie<>(map);
Assert.assertEquals(3, trie.size());  // fail; actual=2
}{code}
In the above example, the resulting trie has only two keys: "x\u" and 
"x\uy". The key "x" gets overwritten. Here is another way to repro the bug: 
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.containsKey("x")); // fail
}
{code}
In the above example, the key "x" suddenly disappears when an entry with key 
"x\u" is inserted.

The PatriciaKey docs do not mention anything about null terminated strings. In 
general, I believe this also breaks the JDK Map contract since the keys 
"x".equals("x\u") is false. 

This bug was found automatically using JQF: 
[https://github.com/rohanpadhye/jqf].

 


> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char) 
> is different from the string "x\u" (of length = 2 chars). However, 
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce: 
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1);   // key of length 2
> map.put("x\uy", 2);  // key of length 3
> Assert.assertEquals(3, map.size());  // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size());  // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and 
> "x\uy". The key "x" gets overwritten. Here is another way to repro the 
> bug: 
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key 
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings. 
> In general, I believe this also breaks the JDK Map contract since the keys 
> "x".equals("x\u") is false. 
> This bug was found automatically using JQF: 
> 

[jira] [Updated] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys

[Rohan Padhye (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohan Padhye updated COLLECTIONS-714:
-
Description: 
In Java, strings are not null terminated. The string "x" (of length = 1 char) 
is different from the string "x\u" (of length = 2 chars). However, 
PatriciaTrie does not seem to distinguish between these strings.

To reproduce: 
{code:java}
@Test
public void testNullTerminatedKey1() {
Map map = new HashMap<>();
map.put("x", 0); // key of length 1
map.put("x\u", 1);   // key of length 2
map.put("x\uy", 2);  // key of length 3
Assert.assertEquals(3, map.size());  // ok, 3 distinct keys

PatriciaTrie trie = new PatriciaTrie<>(map);
Assert.assertEquals(3, trie.size());  // fail; actual=2
}{code}
In the above example, the resulting trie has only two keys: "x\u" and 
"x\uy". The key "x" gets overwritten. Here is another way to repro the bug: 
{code:java}
@Test
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.containsKey("x")); // fail
}
{code}
In the above example, the key "x" suddenly disappears when an entry with key 
"x\u" is inserted.

The PatriciaKey docs do not mention anything about null terminated strings. In 
general, I believe this also breaks the JDK Map contract since the keys 
"x".equals("x\u") is false. 

This bug was found automatically using JQF: 
[https://github.com/rohanpadhye/jqf].

 

  was:
In Java, strings are not null terminated. The string "x" (of length = 1 char) 
is different from the string "x\u" (of length = 2 chars). However, 
PatriciaTrie does not seem to distinguish between these strings.

To reproduce: 
{code:java}
@Test
public void testNullTerminatedKey1() {
Map map = new HashMap<>();
map.put("x", 0); // key of length 1
map.put("x\u", 1);   // key of length 2
map.put("x\uy", 2);  // key of length 3
Assert.assertEquals(3, map.size());  // ok, 3 distinct keys

PatriciaTrie trie = new PatriciaTrie<>(map);
Assert.assertEquals(3, trie.size());  // fail; actual=2
}{code}
In the above example, the resulting trie has only two keys: "x\u" and 
"x\uy". The key "x" gets overwritten. Here is another way to repro the bug: 
{code:java}
@Test
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.containsKey("x")); // fail
}
{code}
In the above example, the key "x" suddenly disappears when an entry with key 
"x\u" is inserted.

The PatriciaKey docs do not mention anything about null terminated strings. In 
general, I believe this also breaks the JDK Map contract since the keys 
"x".equals("x\u") is false. 

This bug was found automatically using 
[JQF|[https://github.com/rohanpadhye/jqf]].

 


> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char) 
> is different from the string "x\u" (of length = 2 chars). However, 
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce: 
> {code:java}
> @Test
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1);   // key of length 2
> map.put("x\uy", 2);  // key of length 3
> Assert.assertEquals(3, map.size());  // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size());  // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and 
> "x\uy". The key "x" gets overwritten. Here is another way to repro the 
> bug: 
> {code:java}
> @Test
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key 
> "x\u" is inserted.
> The PatriciaKey docs do not mention anything about null terminated strings. 
> In general, I believe this also breaks the JDK Map contract since the keys 
> "x".equals("x\u") is false. 
> This bug 

[jira] [Updated] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys

[Rohan Padhye (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohan Padhye updated COLLECTIONS-714:
-
Description: 
In Java, strings are not null terminated. The string "x" (of length = 1 char) 
is different from the string "x\u" (of length = 2 chars). However, 
PatriciaTrie does not seem to distinguish between these strings.

To reproduce: 
{code:java}
public void testNullTerminatedKey1() {
Map map = new HashMap<>();
map.put("x", 0); // key of length 1
map.put("x\u", 1);   // key of length 2
map.put("x\uy", 2);  // key of length 3
Assert.assertEquals(3, map.size());  // ok, 3 distinct keys

PatriciaTrie trie = new PatriciaTrie<>(map);
Assert.assertEquals(3, trie.size());  // fail; actual=2
}{code}
In the above example, the resulting trie has only two keys: "x\u" and 
"x\uy". The key "x" gets overwritten. Here is another way to repro the bug: 
{code:java}
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.containsKey("x")); // fail
}
{code}
In the above example, the key "x" suddenly disappears when an entry with key 
"x\u" is inserted.

The PatriciaKey docs do not mention anything about null terminated strings. In 
general, I believe this also breaks the JDK Map contract since the keys 
"x".equals("x\u") is false. 

This bug was found automatically using JQF: 
[https://github.com/rohanpadhye/jqf].

 

  was:
In Java, strings are not null terminated. The string "x" (of length = 1 char) 
is different from the string "x\u" (of length = 2 chars). However, 
PatriciaTrie does not seem to distinguish between these strings.

To reproduce: 
{code:java}
@Test
public void testNullTerminatedKey1() {
Map map = new HashMap<>();
map.put("x", 0); // key of length 1
map.put("x\u", 1);   // key of length 2
map.put("x\uy", 2);  // key of length 3
Assert.assertEquals(3, map.size());  // ok, 3 distinct keys

PatriciaTrie trie = new PatriciaTrie<>(map);
Assert.assertEquals(3, trie.size());  // fail; actual=2
}{code}
In the above example, the resulting trie has only two keys: "x\u" and 
"x\uy". The key "x" gets overwritten. Here is another way to repro the bug: 
{code:java}
@Test
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.containsKey("x")); // fail
}
{code}
In the above example, the key "x" suddenly disappears when an entry with key 
"x\u" is inserted.

The PatriciaKey docs do not mention anything about null terminated strings. In 
general, I believe this also breaks the JDK Map contract since the keys 
"x".equals("x\u") is false. 

This bug was found automatically using JQF: 
[https://github.com/rohanpadhye/jqf].

 


> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char) 
> is different from the string "x\u" (of length = 2 chars). However, 
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce: 
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1);   // key of length 2
> map.put("x\uy", 2);  // key of length 3
> Assert.assertEquals(3, map.size());  // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size());  // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and 
> "x\uy". The key "x" gets overwritten. Here is another way to repro the 
> bug: 
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key 
> "x\u" is inserted.
> The PatriciaKey docs do not mention anything about null terminated strings. 
> In general, I believe this also breaks the JDK Map contract since the keys 
> "x".equals("x\u") is false. 
> This bug was found automatically using 

[jira] [Created] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys

[Rohan Padhye (JIRA)]

Rohan Padhye created COLLECTIONS-714:


 Summary: PatriciaTrie ignores trailing null characters in keys
 Key: COLLECTIONS-714
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
 Project: Commons Collections
  Issue Type: Bug
  Components: Collection, Map
Affects Versions: 4.3
Reporter: Rohan Padhye


In Java, strings are not null terminated. The string "x" (of length = 1 char) 
is different from the string "x\u" (of length = 2 chars). However, 
PatriciaTrie does not seem to distinguish between these strings.

To reproduce: 
{code:java}
@Test
public void testNullTerminatedKey1() {
Map map = new HashMap<>();
map.put("x", 0); // key of length 1
map.put("x\u", 1);   // key of length 2
map.put("x\uy", 2);  // key of length 3
Assert.assertEquals(3, map.size());  // ok, 3 distinct keys

PatriciaTrie trie = new PatriciaTrie<>(map);
Assert.assertEquals(3, trie.size());  // fail; actual=2
}{code}
In the above example, the resulting trie has only two keys: "x\u" and 
"x\uy". The key "x" gets overwritten. Here is another way to repro the bug: 
{code:java}
@Test
public void testNullTerminatedKey2() {
PatriciaTrie trie = new PatriciaTrie<>();
trie.put("x", 0);
Assert.assertTrue(trie.containsKey("x")); // ok
trie.put("x\u", 1);
Assert.assertTrue(trie.containsKey("x")); // fail
}
{code}
In the above example, the key "x" suddenly disappears when an entry with key 
"x\u" is inserted.

The PatriciaKey docs do not mention anything about null terminated strings. In 
general, I believe this also breaks the JDK Map contract since the keys 
"x".equals("x\u") is false. 

This bug was found automatically using 
[JQF|[https://github.com/rohanpadhye/jqf]].

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (BCEL-313) ClassFormatException: Invalid signature: Ljava/lang/String)V in Verifier Pass 3A

[Rohan Padhye (JIRA)]

Rohan Padhye created BCEL-313:
-

 Summary: ClassFormatException: Invalid signature: 
Ljava/lang/String)V in Verifier Pass 3A
 Key: BCEL-313
 URL: https://issues.apache.org/jira/browse/BCEL-313
 Project: Commons BCEL
  Issue Type: Bug
  Components: Verifier
Affects Versions: 6.2
Reporter: Rohan Padhye
 Attachments: Hello.class

h1.  

Verifier pass 3A throws an unchecked ClassFormatException when presented with 
malformed input instead of returning a VERIFIER_REJECTED.
h1. Steps to reproduce:

 

Save the attached file as "Hello.class" and run:

java -cp  org.apache.bcel.verifier.Verifier Hello

 

The file Hello.class was generated automatically by the fuzzer JQF 
([https://github.com/rohanpadhye/jqf]).
h2. Expected output:

VERIFIED_REJECTED
h2. Observed output:

JustIce by Enver Haase, (C) 2001-2002.





Now verifying: Hello

 

Pass 1:

VERIFIED_OK

Passed verification.

 

Pass 2:

VERIFIED_OK

Passed verification.

 

Pass 3a, method number 0 ['public void ()']:

VERIFIED_OK

Passed verification.

 

Pass 3b, method number 0 ['public void ()']:

VERIFIED_OK

Passed verification.

 

Exception in thread "main" org.apache.bcel.classfile.ClassFormatException: 
Invalid signature: Ljava/lang/String)V

 at org.apache.bcel.classfile.Utility.signatureToString(Utility.java:850)

 at org.apache.bcel.generic.Type.getType(Type.java:217)

 at org.apache.bcel.generic.Type.getArgumentTypes(Type.java:256)

 at 
org.apache.bcel.generic.InvokeInstruction.getArgumentTypes(InvokeInstruction.java:134)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.visitInvokeInstruction(Pass3aVerifier.java:721)

 at org.apache.bcel.generic.INVOKEVIRTUAL.accept(INVOKEVIRTUAL.java:88)

 at org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:302)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier.pass3StaticInstructionOperandsChecks(Pass3aVerifier.java:443)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier.do_verify(Pass3aVerifier.java:208)

 at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:71)

 at org.apache.bcel.verifier.Verifier.doPass3a(Verifier.java:89)

 at org.apache.bcel.verifier.Verifier.main(Verifier.java:216)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (BCEL-312) AssertionViolation: INTERNAL ERROR Please adapt StringRepresentation to deal with ConstantPackage in Verifier Pass 2

[Rohan Padhye (JIRA)]

Rohan Padhye created BCEL-312:
-

 Summary: AssertionViolation: INTERNAL ERROR Please adapt 
StringRepresentation to deal with ConstantPackage in Verifier Pass 2
 Key: BCEL-312
 URL: https://issues.apache.org/jira/browse/BCEL-312
 Project: Commons BCEL
  Issue Type: Bug
  Components: Verifier
Affects Versions: 6.2
Reporter: Rohan Padhye
 Attachments: Hello.class

Verifier pass 2 throws an INTERNAL ERROR on malformed input instead of 
reporting verification failure.
h1. Steps to reproduce:

 

Save the attached file as "Hello.class" and run:

java -cp  org.apache.bcel.verifier.Verifier Hello

 

The file Hello.class was generated automatically by the fuzzer JQF 
([https://github.com/rohanpadhye/jqf]).
h2. Expected output:

VERIFIED_REJECTED
h2. Observed output:

JustIce by Enver Haase, (C) 2001-2002.





 

Now verifying: Hello

 

Pass 1:

VERIFIED_OK

Passed verification.

 

Exception in thread "main" 
org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: Please 
adapt 'class org.apache.bcel.verifier.statics.StringRepresentation' to deal 
with objects of class 'class org.apache.bcel.classfile.ConstantPackage'.

 at 
org.apache.bcel.verifier.statics.StringRepresentation.toString(StringRepresentation.java:110)

 at 
org.apache.bcel.verifier.statics.Pass2Verifier.tostring(Pass2Verifier.java:1569)

 at 
org.apache.bcel.verifier.statics.Pass2Verifier.access$100(Pass2Verifier.java:86)

 at 
org.apache.bcel.verifier.statics.Pass2Verifier$CPESSC_Visitor.checkIndex(Pass2Verifier.java:371)

 at 
org.apache.bcel.verifier.statics.Pass2Verifier$CPESSC_Visitor.visitConstantFieldref(Pass2Verifier.java:452)

 at org.apache.bcel.classfile.ConstantFieldref.accept(ConstantFieldref.java:69)

 at 
org.apache.bcel.classfile.DescendingVisitor.visitConstantFieldref(DescendingVisitor.java:295)

 at org.apache.bcel.classfile.ConstantFieldref.accept(ConstantFieldref.java:69)

 at 
org.apache.bcel.classfile.DescendingVisitor.visitConstantPool(DescendingVisitor.java:269)

 at org.apache.bcel.classfile.ConstantPool.accept(ConstantPool.java:91)

 at 
org.apache.bcel.classfile.DescendingVisitor.visitJavaClass(DescendingVisitor.java:105)

 at org.apache.bcel.classfile.JavaClass.accept(JavaClass.java:213)

 at org.apache.bcel.classfile.DescendingVisitor.visit(DescendingVisitor.java:85)

 at 
org.apache.bcel.verifier.statics.Pass2Verifier$CPESSC_Visitor.(Pass2Verifier.java:361)

 at 
org.apache.bcel.verifier.statics.Pass2Verifier$CPESSC_Visitor.(Pass2Verifier.java:317)

 at 
org.apache.bcel.verifier.statics.Pass2Verifier.constant_pool_entries_satisfy_static_constraints(Pass2Verifier.java:302)

 at 
org.apache.bcel.verifier.statics.Pass2Verifier.do_verify(Pass2Verifier.java:161)

 at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:71)

 at org.apache.bcel.verifier.Verifier.doPass2(Verifier.java:76)

 at org.apache.bcel.verifier.Verifier.main(Verifier.java:211)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (BCEL-311) ClassCastException in Verifier Pass 2

[Rohan Padhye (JIRA)]

Rohan Padhye created BCEL-311:
-

 Summary: ClassCastException in Verifier Pass 2
 Key: BCEL-311
 URL: https://issues.apache.org/jira/browse/BCEL-311
 Project: Commons BCEL
  Issue Type: Bug
  Components: Verifier
Affects Versions: 6.2
Reporter: Rohan Padhye
 Attachments: Hello.class

Verifier throws ClassCastException on malformed input instead of reporting 
verification failure.
h1. Steps to reproduce:

 

Save the attached file as "Hello.class" and run:

java -cp  org.apache.bcel.verifier.Verifier Hello

 

The file Hello.class was generated automatically by the fuzzer JQF 
([https://github.com/rohanpadhye/jqf]).
h2. Expected output:

VERIFIED_REJECTED
h2. Observed output:

JustIce by Enver Haase, (C) 2001-2002.





 

Now verifying: Hello

 

Pass 1:

VERIFIED_OK

Passed verification.

 

Exception in thread "main" java.lang.ClassCastException: Illegal constant 
'CONSTANT_Class[7](name_index = 21)' at index '5'. '<>' expects a 
'class org.apache.bcel.classfile.ConstantUtf8'.

 at 
org.apache.bcel.verifier.statics.Pass2Verifier$CPESSC_Visitor.checkIndex(Pass2Verifier.java:372)

 at 
org.apache.bcel.verifier.statics.Pass2Verifier$CPESSC_Visitor.visitMethod(Pass2Verifier.java:622)

 at org.apache.bcel.classfile.Method.accept(Method.java:108)

 at 
org.apache.bcel.classfile.DescendingVisitor.visitMethod(DescendingVisitor.java:159)

 at org.apache.bcel.classfile.Method.accept(Method.java:108)

 at 
org.apache.bcel.classfile.DescendingVisitor.visitJavaClass(DescendingVisitor.java:99)

 at org.apache.bcel.classfile.JavaClass.accept(JavaClass.java:213)

 at org.apache.bcel.classfile.DescendingVisitor.visit(DescendingVisitor.java:85)

 at 
org.apache.bcel.verifier.statics.Pass2Verifier$CPESSC_Visitor.(Pass2Verifier.java:361)

 at 
org.apache.bcel.verifier.statics.Pass2Verifier$CPESSC_Visitor.(Pass2Verifier.java:317)

 at 
org.apache.bcel.verifier.statics.Pass2Verifier.constant_pool_entries_satisfy_static_constraints(Pass2Verifier.java:302)

 at 
org.apache.bcel.verifier.statics.Pass2Verifier.do_verify(Pass2Verifier.java:161)

 at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:71)

 at org.apache.bcel.verifier.Verifier.doPass2(Verifier.java:76)

 at org.apache.bcel.verifier.Verifier.main(Verifier.java:211)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (BCEL-310) ArrayIndexOutOfBounds in Verifier Pass 3A

[Rohan Padhye (JIRA)]

Rohan Padhye created BCEL-310:
-

 Summary: ArrayIndexOutOfBounds in Verifier Pass 3A
 Key: BCEL-310
 URL: https://issues.apache.org/jira/browse/BCEL-310
 Project: Commons BCEL
  Issue Type: Bug
  Components: Verifier
Affects Versions: 6.2
Reporter: Rohan Padhye
 Attachments: Hello.class

Verifier throws OOB on malformed input instead of reporting verification 
failure.
h1. Steps to reproduce:

 

Save the attached file as "Hello.class" and run:

java -cp  org.apache.bcel.verifier.Verifier Hello

 

The file Hello.class was generated automatically by the fuzzer JQF 
([https://github.com/rohanpadhye/jqf]).
h2. Expected output:

VERIFIED_REJECTED
h2. Observed output:

JustIce by Enver Haase, (C) 2001-2002.





 

Now verifying: Hello

 

Pass 1:

VERIFIED_OK

Passed verification.

 

Pass 2:

VERIFIED_OK

Passed verification.

 

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -73

 at org.apache.bcel.Const.getTypeName(Const.java:1799)

 at org.apache.bcel.generic.NEWARRAY.toString(NEWARRAY.java:90)

 at org.apache.bcel.generic.Instruction.toString(Instruction.java:101)

 at java.lang.String.valueOf(String.java:2994)

 at java.lang.StringBuilder.append(StringBuilder.java:131)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.constraintViolated(Pass3aVerifier.java:499)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.visitNEWARRAY(Pass3aVerifier.java:835)

 at org.apache.bcel.generic.NEWARRAY.accept(NEWARRAY.java:125)

 at org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:302)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier.pass3StaticInstructionOperandsChecks(Pass3aVerifier.java:443)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier.do_verify(Pass3aVerifier.java:208)

 at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:71)

 at org.apache.bcel.verifier.Verifier.doPass3a(Verifier.java:8



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (BCEL-309) NegativeArraySizeException when Code attribute length is negative

[Rohan Padhye (JIRA)]

Rohan Padhye created BCEL-309:
-

 Summary: NegativeArraySizeException when Code attribute length is 
negative
 Key: BCEL-309
 URL: https://issues.apache.org/jira/browse/BCEL-309
 Project: Commons BCEL
  Issue Type: Bug
  Components: Parser
Affects Versions: 6.2
Reporter: Rohan Padhye
 Attachments: Hello.class

Class parser throws an undocumented NegativeArraySizeException when parsing a 
malformed class file.
h1. Steps to reproduce:

 

 

Attempt to parse the attached file "Hello.class" using the API

org.apache.bcel.classfile.ClassParser.parse(java.io.InputStream)

 

The file Hello.class was generated automatically by the fuzzer JQF 
([https://github.com/rohanpadhye/jqf]).
h2. Expected output:

ClassFormatException should be thrown as the class file is malformed.
h2. Observed output:

Undocumented run-time exception is thrown:

java.lang.NegativeArraySizeException

 at org.apache.bcel.classfile.Code.(Code.java:75)

 at org.apache.bcel.classfile.Attribute.readAttribute(Attribute.java:220)

 at org.apache.bcel.classfile.FieldOrMethod.(FieldOrMethod.java:109)

 at org.apache.bcel.classfile.Method.(Method.java:82)

 at org.apache.bcel.classfile.ClassParser.readMethods(ClassParser.java:294)

 at org.apache.bcel.classfile.ClassParser.parse(ClassParser.java:153)

 

 

This is probably because the length of the Code attribute in a method is read 
as a 4-byte signed integer, an an array of that size is allocated without 
checking to see if the integer is negative.

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (BCEL-308) NullPointerException in Verifier Pass 3A

[Rohan Padhye (JIRA)]

Rohan Padhye created BCEL-308:
-

 Summary: NullPointerException in Verifier Pass 3A
 Key: BCEL-308
 URL: https://issues.apache.org/jira/browse/BCEL-308
 Project: Commons BCEL
  Issue Type: Bug
  Components: Verifier
Affects Versions: 6.2
Reporter: Rohan Padhye
 Attachments: Hello.class

Verifier throws NPE on malformed input instead of reporting verification 
failure.
h1. Steps to reproduce:

 

Save the attached file as "Hello.class" and run:

java -cp  org.apache.bcel.verifier.Verifier Hello

 

The file Hello.class was generated automatically by the fuzzer JQF 
([https://github.com/rohanpadhye/jqf]).
h2. Expected output:

VERIFIED_REJECTED
h2. Observed output:

JustIce by Enver Haase, (C) 2001-2002.





 

Now verifying: Hello

 

Pass 1:

VERIFIED_OK

Passed verification.

 

Pass 2:

VERIFIED_OK

Passed verification.

 

Exception in thread "main" java.lang.NullPointerException

 at 
org.apache.bcel.generic.FieldOrMethod.getReferenceType(FieldOrMethod.java:116)

 at 
org.apache.bcel.generic.FieldOrMethod.getLoadClassType(FieldOrMethod.java:133)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.visitLoadClass(Pass3aVerifier.java:521)

 at org.apache.bcel.generic.INVOKESPECIAL.accept(INVOKESPECIAL.java:86)

 at org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:302)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier.pass3StaticInstructionOperandsChecks(Pass3aVerifier.java:443)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier.do_verify(Pass3aVerifier.java:208)

 at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:71)

 at org.apache.bcel.verifier.Verifier.doPass3a(Verifier.java:89)

 at org.apache.bcel.verifier.Verifier.main(Verifier.java:216)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (BCEL-307) ClassFormatException thrown in Pass 3A verification

[Rohan Padhye (JIRA)]

[ 
https://issues.apache.org/jira/browse/BCEL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588361#comment-16588361
 ] 

Rohan Padhye commented on BCEL-307:
---

The bug occurs when Pass 3A is attempting to internally throw a 
ClassConstraintException (which if thrown properly would indeed result in the 
expected VERIFICATION_REJECTED); however, the generation of the error message 
for this exception itself fails when attempting to call the toString() method 
on the Code attribute, leading to the uncaught ClassFormatException leaking out 
of the API.

 

> ClassFormatException thrown in Pass 3A verification
> ---
>
> Key: BCEL-307
> URL: https://issues.apache.org/jira/browse/BCEL-307
> Project: Commons BCEL
>  Issue Type: Bug
>  Components: Verifier
>Affects Versions: 6.2
>Reporter: Rohan Padhye
>Priority: Major
> Attachments: A.class
>
>
> The verifier throws a ClassFormatException during Pass 3A verification of a 
> malformed class file even though Pass 1 and Pass 2 have completed 
> successfully.
> Note that the input class file is indeed malformed, however the verifier 
> should ideally just return a verification result of REJECTED instead of 
> throwing an unchecked run-time exception.
> h1. Steps to reproduce:
>  
> Save the attached file as "example/A.class" and run:
> java -cp  org.apache.bcel.verifier.Verifier example.A
>  
> The file A.class was generated automatically by the fuzzer JQF 
> ([https://github.com/rohanpadhye/jqf]).
> h2. Expected output:
> VERIFIED_REJECTED
> h2. Observed output:
> JustIce by Enver Haase, (C) 2001-2002.
> 
> 
>  
> Now verifying: example.A
>  
> Pass 1:
> VERIFIED_OK
> Passed verification.
>  
> Pass 2:
> VERIFIED_OK
> Passed verification.
>  
> Exception in thread "main" org.apache.bcel.classfile.ClassFormatException: 
> Expected class `CONSTANT_InvokeDynamic' at index 14 and got 
> CONSTANT_Methodref[10](class_index = 13, name_and_type_index = 11)
>  at org.apache.bcel.classfile.ConstantPool.getConstant(ConstantPool.java:261)
>  at 
> org.apache.bcel.classfile.ConstantPool.constantToString(ConstantPool.java:207)
>  at org.apache.bcel.classfile.Utility.codeToString(Utility.java:373)
>  at org.apache.bcel.classfile.Utility.codeToString(Utility.java:157)
>  at org.apache.bcel.classfile.Code.toString(Code.java:306)
>  at org.apache.bcel.classfile.Code.toString(Code.java:328)
>  at java.lang.String.valueOf(String.java:2994)
>  at java.lang.StringBuilder.append(StringBuilder.java:131)
>  at 
> org.apache.bcel.verifier.statics.Pass3aVerifier.delayedPass2Checks(Pass3aVerifier.java:289)
>  at 
> org.apache.bcel.verifier.statics.Pass3aVerifier.do_verify(Pass3aVerifier.java:200)
>  at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:71)
>  at org.apache.bcel.verifier.Verifier.doPass3a(Verifier.java:89)
>  at org.apache.bcel.verifier.Verifier.main(Verifier.java:216)
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (BCEL-307) ClassFormatException thrown in Pass 3A verification

[Rohan Padhye (JIRA)]

Rohan Padhye created BCEL-307:
-

 Summary: ClassFormatException thrown in Pass 3A verification
 Key: BCEL-307
 URL: https://issues.apache.org/jira/browse/BCEL-307
 Project: Commons BCEL
  Issue Type: Bug
  Components: Verifier
Affects Versions: 6.2
Reporter: Rohan Padhye
 Attachments: A.class

The verifier throws a ClassFormatException during Pass 3A verification of a 
malformed class file even though Pass 1 and Pass 2 have completed successfully.

Note that the input class file is indeed malformed, however the verifier should 
ideally just return a verification result of REJECTED instead of throwing an 
unchecked run-time exception.
h1. Steps to reproduce:

 

Save the attached file as "example/A.class" and run:

java -cp  org.apache.bcel.verifier.Verifier example.A

 

The file A.class was generated automatically by the fuzzer JQF 
([https://github.com/rohanpadhye/jqf]).
h2. Expected output:

VERIFIED_REJECTED
h2. Observed output:

JustIce by Enver Haase, (C) 2001-2002.





 

Now verifying: example.A

 

Pass 1:

VERIFIED_OK

Passed verification.

 

Pass 2:

VERIFIED_OK

Passed verification.

 

Exception in thread "main" org.apache.bcel.classfile.ClassFormatException: 
Expected class `CONSTANT_InvokeDynamic' at index 14 and got 
CONSTANT_Methodref[10](class_index = 13, name_and_type_index = 11)

 at org.apache.bcel.classfile.ConstantPool.getConstant(ConstantPool.java:261)

 at 
org.apache.bcel.classfile.ConstantPool.constantToString(ConstantPool.java:207)

 at org.apache.bcel.classfile.Utility.codeToString(Utility.java:373)

 at org.apache.bcel.classfile.Utility.codeToString(Utility.java:157)

 at org.apache.bcel.classfile.Code.toString(Code.java:306)

 at org.apache.bcel.classfile.Code.toString(Code.java:328)

 at java.lang.String.valueOf(String.java:2994)

 at java.lang.StringBuilder.append(StringBuilder.java:131)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier.delayedPass2Checks(Pass3aVerifier.java:289)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier.do_verify(Pass3aVerifier.java:200)

 at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:71)

 at org.apache.bcel.verifier.Verifier.doPass3a(Verifier.java:89)

 at org.apache.bcel.verifier.Verifier.main(Verifier.java:216)

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (BCEL-303) AssertionViolatedException in Pass 3A Verification of invoke instructions

[Rohan Padhye (JIRA)]

Rohan Padhye created BCEL-303:
-

 Summary: AssertionViolatedException in Pass 3A Verification of 
invoke instructions
 Key: BCEL-303
 URL: https://issues.apache.org/jira/browse/BCEL-303
 Project: Commons BCEL
  Issue Type: Bug
  Components: Verifier
Affects Versions: 6.2
Reporter: Rohan Padhye
 Attachments: A.class

The verifier throws an assertion violation / INTERNAL ERROR in pass 3A when 
verifying a malformed class file.

As I understand it, the issue is that if class A implements interface B, then 
class A can be pass stage 1 verification even if class B is not resolved. 
However, pass 3A verification of code that invokes a method defined on class A 
assumes that the receiver type and all its interfaces are fully resolved.
h1. Steps to reproduce:

 

Save the attached file as "example/A.class" and run:

java -cp  org.apache.bcel.verifier.Verifier example.A

 

The file A.class was generated automatically by the fuzzer JQF 
(https://github.com/rohanpadhye/jqf).
h2. Expected output:

VERIFIED_REJECTED
h2. Observed output:

JustIce by Enver Haase, (C) 2001-2002.





 

Now verifying: example.A

 

Pass 1:

VERIFIED_OK

Passed verification.

 

Pass 2:

VERIFIED_OK

Passed verification.

 

Exception in thread "main" 
org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: 
Missing class: java.lang.ClassNotFoundException: Exception while looking for 
class example.I0: java.io.IOException: Couldn't find: example/I0.class

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.visitINVOKEVIRTUAL(Pass3aVerifier.java:1315)

 at org.apache.bcel.generic.INVOKEVIRTUAL.accept(INVOKEVIRTUAL.java:89)

 at org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:302)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier.pass3StaticInstructionOperandsChecks(Pass3aVerifier.java:443)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier.do_verify(Pass3aVerifier.java:208)

 at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:71)

 at org.apache.bcel.verifier.Verifier.doPass3a(Verifier.java:89)

 at org.apache.bcel.verifier.Verifier.main(Verifier.java:216)

Caused by: java.lang.ClassNotFoundException: Exception while looking for class 
example.I0: java.io.IOException: Couldn't find: example/I0.class

 at 
org.apache.bcel.util.MemorySensitiveClassPathRepository.loadClass(MemorySensitiveClassPathRepository.java:97)

 at org.apache.bcel.classfile.JavaClass.getInterfaces(JavaClass.java:847)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.getMethodRecursive(Pass3aVerifier.java:1181)

 at 
org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.visitINVOKEVIRTUAL(Pass3aVerifier.java:1304)

 ... 7 more

Caused by: java.io.IOException: Couldn't find: example/I0.class

 at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:279)

 at org.apache.bcel.util.ClassPath.getInputStream(ClassPath.java:209)

 at org.apache.bcel.util.ClassPath.getInputStream(ClassPath.java:188)

 at 
org.apache.bcel.util.MemorySensitiveClassPathRepository.loadClass(MemorySensitiveClassPathRepository.java:95)

 ... 10 more

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (LANG-1385) NumberUtils.createNumber() throws StringIndexOutOfBoundsException instead of NumberFormatException

[Rohan Padhye (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohan Padhye closed LANG-1385.
--

> NumberUtils.createNumber() throws StringIndexOutOfBoundsException  instead of 
> NumberFormatException
> ---
>
> Key: LANG-1385
> URL: https://issues.apache.org/jira/browse/LANG-1385
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.math.*
>Affects Versions: 3.7
>Reporter: Rohan Padhye
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 3.8
>
>
> Test case:
> {noformat}
> NumberUtils.createNumber("L"){noformat}
> Expected: {{NumberFormatException}}
> Got:
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> at java.lang.String.charAt(String.java:658)
>  at 
> org.apache.commons.lang3.math.NumberUtils.createNumber(NumberUtils.java:528)
> {noformat}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1385) NumberUtils.createNumber() throws StringIndexOutOfBoundsException instead of NumberFormatException

[Rohan Padhye (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394378#comment-16394378
 ] 

Rohan Padhye commented on LANG-1385:


Great! Thanks for the quick response, [~garydgregory].

> NumberUtils.createNumber() throws StringIndexOutOfBoundsException  instead of 
> NumberFormatException
> ---
>
> Key: LANG-1385
> URL: https://issues.apache.org/jira/browse/LANG-1385
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.math.*
>Affects Versions: 3.7
>Reporter: Rohan Padhye
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 3.8
>
>
> Test case:
> {noformat}
> NumberUtils.createNumber("L"){noformat}
> Expected: {{NumberFormatException}}
> Got:
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> at java.lang.String.charAt(String.java:658)
>  at 
> org.apache.commons.lang3.math.NumberUtils.createNumber(NumberUtils.java:528)
> {noformat}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (LANG-1385) StringIndexOutOfBoundsException in NumberUtils.createNumber

[Rohan Padhye (JIRA)]

Rohan Padhye created LANG-1385:
--

 Summary: StringIndexOutOfBoundsException in 
NumberUtils.createNumber
 Key: LANG-1385
 URL: https://issues.apache.org/jira/browse/LANG-1385
 Project: Commons Lang
  Issue Type: Bug
  Components: lang.math.*
Affects Versions: 3.7
Reporter: Rohan Padhye


Test case:
{noformat}
NumberUtils.createNumber("L"){noformat}

Expected: {{NumberFormatException}}

Got:
{noformat}
java.lang.StringIndexOutOfBoundsException: String index out of range: 0
at java.lang.String.charAt(String.java:658)
 at org.apache.commons.lang3.math.NumberUtils.createNumber(NumberUtils.java:528)
{noformat}
 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (COMPRESS-424) [bzip2] Multiple ArrayIndexOutOfBoundsException(s) when decompressing malformed input

[Rohan Padhye (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16267172#comment-16267172
 ] 

Rohan Padhye commented on COMPRESS-424:
---

To be fair, the JVM does insert those bounds checks anyway in order to decide 
whether or not throw an exception, so I am not sure how _considerable_ the slow 
down would be with additional bounds check in Java.

That said, if several sources of {{ArrayIndexOutOfBounds}} are expected, then 
indeed catching them and throwing an {{IOException}} instead would make the 
implementation consistent with the API specification. My primary concern is 
that applications that process user-derived input files should expect the 
decompression to either succeed or to fail using an {{IOException}}, such that 
they can handle either case in an application-specific way (e.g. show an error 
message to the end-user). Throwing an undocumented unchecked exception would 
probably lead such an application to crash unexpectedly or log the error in a 
top-level exception handling mechanism instead of gracefully interacting with 
the end-user. Consequently, developers using the bzip2 API would be forced to 
explicitly handle {{ArrayIndexOutOfBounds}}, but this seems like an 
implementation detail that is being leaked outside.

The risk with this approach, of course, is that any {{ArrayIndexOutOfBounds}} 
would be wrapped in an {{IOException}}, even if there was a genuine bug in 
processing a well-formed file (and would thus make such a hypothetical bug 
slightly harder to detect).

> [bzip2] Multiple ArrayIndexOutOfBoundsException(s) when decompressing 
> malformed input
> -
>
> Key: COMPRESS-424
> URL: https://issues.apache.org/jira/browse/COMPRESS-424
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Compressors
>Affects Versions: 1.14, 1.15
>Reporter: Rohan Padhye
>Priority: Minor
> Attachments: bad1.bz2, bad2.bz2, bad3.bz2
>
>
> Encountered multiple unchecked exceptions thrown from 
> {{BZip2CompressorInputStream.}} when parsing malformed files. 
> {{ArrayIndexOutOfBoundsException}} is an unchecked exception that is not 
> documented in this API; therefore, such exceptions can cause stability issues 
> in applications that are not expecting them. Instead, an {{IOException}} 
> should be thrown indicating that the input stream contains malformed data.
> Stack traces for three distinct (but possibly related) sources of exceptions 
> follow:
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 65536
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.hbCreateDecodeTables(BZip2CompressorInputStream.java:422)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.createHuffmanDecodingTables(BZip2CompressorInputStream.java:546)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.recvDecodingTables(BZip2CompressorInputStream.java:518)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:555)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:324)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:135)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> {noformat}
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 6
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.recvDecodingTables(BZip2CompressorInputStream.java:493)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:555)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:324)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:135)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> {noformat}
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 18002
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:605)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:324)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:135)
>   at 
> 

[jira] [Updated] (COMPRESS-424) [bzip2] Multiple ArrayIndexOutOfBoundsException(s) when decompressing malformed input

[Rohan Padhye (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohan Padhye updated COMPRESS-424:
--
Attachment: bad1.bz2
bad2.bz2
bad3.bz2

> [bzip2] Multiple ArrayIndexOutOfBoundsException(s) when decompressing 
> malformed input
> -
>
> Key: COMPRESS-424
> URL: https://issues.apache.org/jira/browse/COMPRESS-424
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Compressors
>Affects Versions: 1.14, 1.15
>Reporter: Rohan Padhye
>Priority: Minor
> Attachments: bad1.bz2, bad2.bz2, bad3.bz2
>
>
> Encountered multiple unchecked exceptions thrown from 
> {{BZip2CompressorInputStream.}} when parsing malformed files. 
> {{ArrayIndexOutOfBoundsException}} is an unchecked exception that is not 
> documented in this API; therefore, such exceptions can cause stability issues 
> in applications that are not expecting them. Instead, an {{IOException}} 
> should be thrown indicating that the input stream contains malformed data.
> Stack traces for three distinct (but possibly related) sources of exceptions 
> follow:
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 65536
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.hbCreateDecodeTables(BZip2CompressorInputStream.java:422)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.createHuffmanDecodingTables(BZip2CompressorInputStream.java:546)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.recvDecodingTables(BZip2CompressorInputStream.java:518)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:555)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:324)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:135)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> {noformat}
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 6
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.recvDecodingTables(BZip2CompressorInputStream.java:493)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:555)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:324)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:135)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> {noformat}
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 18002
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:605)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:324)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:135)
>   at 
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
> {noformat}
> The inputs were found by mutating random bytes in a simple well-formed file 
> (a compressed string of zeros).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (COMPRESS-424) [bzip2] Multiple ArrayIndexOutOfBoundsException(s) when decompressing malformed input

[Rohan Padhye (JIRA)]

Rohan Padhye created COMPRESS-424:
-

 Summary: [bzip2] Multiple ArrayIndexOutOfBoundsException(s) when 
decompressing malformed input
 Key: COMPRESS-424
 URL: https://issues.apache.org/jira/browse/COMPRESS-424
 Project: Commons Compress
  Issue Type: Bug
  Components: Compressors
Affects Versions: 1.15, 1.14
Reporter: Rohan Padhye
Priority: Minor


Encountered multiple unchecked exceptions thrown from 
{{BZip2CompressorInputStream.}} when parsing malformed files. 

{{ArrayIndexOutOfBoundsException}} is an unchecked exception that is not 
documented in this API; therefore, such exceptions can cause stability issues 
in applications that are not expecting them. Instead, an {{IOException}} should 
be thrown indicating that the input stream contains malformed data.

Stack traces for three distinct (but possibly related) sources of exceptions 
follow:

{noformat}
java.lang.ArrayIndexOutOfBoundsException: 65536
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.hbCreateDecodeTables(BZip2CompressorInputStream.java:422)
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.createHuffmanDecodingTables(BZip2CompressorInputStream.java:546)
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.recvDecodingTables(BZip2CompressorInputStream.java:518)
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:555)
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:324)
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:135)
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
{noformat}


{noformat}
java.lang.ArrayIndexOutOfBoundsException: 6
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.recvDecodingTables(BZip2CompressorInputStream.java:493)
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:555)
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:324)
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:135)
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)

{noformat}


{noformat}
java.lang.ArrayIndexOutOfBoundsException: 18002
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:605)
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:324)
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:135)
at 
org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112)
{noformat}

The inputs were found by mutating random bytes in a simple well-formed file (a 
compressed string of zeros).





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)