[GitHub] [commons-imaging] StefanOltmann commented on pull request #275: [IMAGING-351] EXIF data corruption during copy
StefanOltmann commented on PR #275: URL: https://github.com/apache/commons-imaging/pull/275#issuecomment-1577974627 Here is my version of this test: https://github.com/RealAshampoo/kim/blob/44dbd2c5f0a182e4d401fd17d14ac0310da04440/src/jvmTest/kotlin/com/ashampoo/kim/format/jpeg/JpegRewriterTest.kt#LL156C1-L156C1 Note how I need to skip some offset fields that change due to the reordering: ``` if (expectedField.tagInfo == ExifTag.EXIF_TAG_EXIF_OFFSET || expectedField.tagInfo == ExifTag.EXIF_TAG_GPSINFO || expectedField.tagInfo == ExifTag.EXIF_TAG_INTEROP_OFFSET || expectedField.tagInfo == TiffTag.TIFF_TAG_JPEG_INTERCHANGE_FORMAT ) continue ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (POOL-412) [GenericKeyedObjectPool] ensureMinIdle not work if last idle evicted
[ https://issues.apache.org/jira/browse/POOL-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed POOL-412. Resolution: Information Provided > [GenericKeyedObjectPool] ensureMinIdle not work if last idle evicted > > > Key: POOL-412 > URL: https://issues.apache.org/jira/browse/POOL-412 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.11.1 >Reporter: Oleksandr Porytskyi >Priority: Major > > I'm trying to use GenericKeyedObjectPool with setMinIdlePerKey(1) and > setTestWhileIdle(true). When object failed validation it is removed but > never add new one. > Evictor has two stages: > 1. In evict() call destroy() -> deregister(key) -> poolMap.remove(k) > For some reason it removes key if there are no more objects of it. > > 2. In ensureMinIdle() -> > for (final K k : poolMap.keySet()) { > ensureMinIdle(k); > } > poolMap does not have my key anymore so will not create object for it. > > Here one test for GenericObjectPool which pass and one for > GenericKeyedObjectPool which not pass for same scenario: > {code:java} > @Test > void testGenericKeyedObjectPool() throws Exception { > BaseKeyedPooledObjectFactory baseKeyedPooledObjectFactory = > new BaseKeyedPooledObjectFactory<>() { > @Override > public Object create(String key) throws Exception { > return null; > } > @Override > public PooledObject wrap(Object value) { > return new DefaultPooledObject<>(value); > } > }; > GenericKeyedObjectPoolConfig genericKeyedObjectPoolConfig = new > GenericKeyedObjectPoolConfig<>(); > int minIdlePerKey = 1; > genericKeyedObjectPoolConfig.setMinIdlePerKey(minIdlePerKey); > > genericKeyedObjectPoolConfig.setTimeBetweenEvictionRuns(Duration.ofSeconds(1)); > genericKeyedObjectPoolConfig.setMinEvictableIdleTime(Duration.ofSeconds(5)); > GenericKeyedObjectPool genericKeyedObjectPool = new > GenericKeyedObjectPool<>( > baseKeyedPooledObjectFactory, genericKeyedObjectPoolConfig); > String key = "key"; > genericKeyedObjectPool.preparePool(key); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericKeyedObjectPool.getNumIdle(key) != minIdlePerKey) > ; > }); > System.out.println("we prepared pool so we have idle"); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericKeyedObjectPool.getNumIdle(key) != 0) > ; > }); > System.out.println("after eviction we have no idle"); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericKeyedObjectPool.getNumIdle(key) != minIdlePerKey) > ; > }); > System.out.println("NEVER HAPPEN: after eviction ensure min idle"); > } > @Test > void testGenericObjectPool() throws Exception { > BasePooledObjectFactory basePooledObjectFactory = new > BasePooledObjectFactory<>() { > @Override > public Object create() throws Exception { > return null; > } > @Override > public PooledObject wrap(Object obj) { > return new DefaultPooledObject<>(obj); > } > }; > GenericObjectPoolConfig genericObjectPoolConfig = new > GenericObjectPoolConfig<>(); > int minIdle = 1; > genericObjectPoolConfig.setTimeBetweenEvictionRuns(Duration.ofSeconds(1)); > genericObjectPoolConfig.setMinIdle(minIdle); > genericObjectPoolConfig.setMinEvictableIdleTime(Duration.ofSeconds(5)); > GenericObjectPool genericObjectPool = new > GenericObjectPool<>(basePooledObjectFactory, > genericObjectPoolConfig); > genericObjectPool.preparePool(); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericObjectPool.getNumIdle() != minIdle) > ; > }); > System.out.println("we prepared pool so we have idle"); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericObjectPool.getNumIdle() != 0) > ; > }); > System.out.println("after eviction we have no idle"); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericObjectPool.getNumIdle() != minIdle) > ; > }); > System.out.println("after eviction ensure min idle"); > } > {code} > As workaround I can't just subclass GenericKeyedObjectPool and alter > deregister as it private. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (POOL-412) [GenericKeyedObjectPool] ensureMinIdle not work if last idle evicted
[ https://issues.apache.org/jira/browse/POOL-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729462#comment-17729462 ] Phil Steitz commented on POOL-412: -- Yes, I would close this. > [GenericKeyedObjectPool] ensureMinIdle not work if last idle evicted > > > Key: POOL-412 > URL: https://issues.apache.org/jira/browse/POOL-412 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.11.1 >Reporter: Oleksandr Porytskyi >Priority: Major > > I'm trying to use GenericKeyedObjectPool with setMinIdlePerKey(1) and > setTestWhileIdle(true). When object failed validation it is removed but > never add new one. > Evictor has two stages: > 1. In evict() call destroy() -> deregister(key) -> poolMap.remove(k) > For some reason it removes key if there are no more objects of it. > > 2. In ensureMinIdle() -> > for (final K k : poolMap.keySet()) { > ensureMinIdle(k); > } > poolMap does not have my key anymore so will not create object for it. > > Here one test for GenericObjectPool which pass and one for > GenericKeyedObjectPool which not pass for same scenario: > {code:java} > @Test > void testGenericKeyedObjectPool() throws Exception { > BaseKeyedPooledObjectFactory baseKeyedPooledObjectFactory = > new BaseKeyedPooledObjectFactory<>() { > @Override > public Object create(String key) throws Exception { > return null; > } > @Override > public PooledObject wrap(Object value) { > return new DefaultPooledObject<>(value); > } > }; > GenericKeyedObjectPoolConfig genericKeyedObjectPoolConfig = new > GenericKeyedObjectPoolConfig<>(); > int minIdlePerKey = 1; > genericKeyedObjectPoolConfig.setMinIdlePerKey(minIdlePerKey); > > genericKeyedObjectPoolConfig.setTimeBetweenEvictionRuns(Duration.ofSeconds(1)); > genericKeyedObjectPoolConfig.setMinEvictableIdleTime(Duration.ofSeconds(5)); > GenericKeyedObjectPool genericKeyedObjectPool = new > GenericKeyedObjectPool<>( > baseKeyedPooledObjectFactory, genericKeyedObjectPoolConfig); > String key = "key"; > genericKeyedObjectPool.preparePool(key); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericKeyedObjectPool.getNumIdle(key) != minIdlePerKey) > ; > }); > System.out.println("we prepared pool so we have idle"); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericKeyedObjectPool.getNumIdle(key) != 0) > ; > }); > System.out.println("after eviction we have no idle"); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericKeyedObjectPool.getNumIdle(key) != minIdlePerKey) > ; > }); > System.out.println("NEVER HAPPEN: after eviction ensure min idle"); > } > @Test > void testGenericObjectPool() throws Exception { > BasePooledObjectFactory basePooledObjectFactory = new > BasePooledObjectFactory<>() { > @Override > public Object create() throws Exception { > return null; > } > @Override > public PooledObject wrap(Object obj) { > return new DefaultPooledObject<>(obj); > } > }; > GenericObjectPoolConfig genericObjectPoolConfig = new > GenericObjectPoolConfig<>(); > int minIdle = 1; > genericObjectPoolConfig.setTimeBetweenEvictionRuns(Duration.ofSeconds(1)); > genericObjectPoolConfig.setMinIdle(minIdle); > genericObjectPoolConfig.setMinEvictableIdleTime(Duration.ofSeconds(5)); > GenericObjectPool genericObjectPool = new > GenericObjectPool<>(basePooledObjectFactory, > genericObjectPoolConfig); > genericObjectPool.preparePool(); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericObjectPool.getNumIdle() != minIdle) > ; > }); > System.out.println("we prepared pool so we have idle"); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericObjectPool.getNumIdle() != 0) > ; > }); > System.out.println("after eviction we have no idle"); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericObjectPool.getNumIdle() != minIdle) > ; > }); > System.out.println("after eviction ensure min idle"); > } > {code} > As workaround I can't just subclass GenericKeyedObjectPool and alter > deregister as it private. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (POOL-412) [GenericKeyedObjectPool] ensureMinIdle not work if last idle evicted
[ https://issues.apache.org/jira/browse/POOL-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729457#comment-17729457 ] Gary D. Gregory commented on POOL-412: -- Thanks for the info [~psteitz]. Ok to close this ticket then? > [GenericKeyedObjectPool] ensureMinIdle not work if last idle evicted > > > Key: POOL-412 > URL: https://issues.apache.org/jira/browse/POOL-412 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.11.1 >Reporter: Oleksandr Porytskyi >Priority: Major > > I'm trying to use GenericKeyedObjectPool with setMinIdlePerKey(1) and > setTestWhileIdle(true). When object failed validation it is removed but > never add new one. > Evictor has two stages: > 1. In evict() call destroy() -> deregister(key) -> poolMap.remove(k) > For some reason it removes key if there are no more objects of it. > > 2. In ensureMinIdle() -> > for (final K k : poolMap.keySet()) { > ensureMinIdle(k); > } > poolMap does not have my key anymore so will not create object for it. > > Here one test for GenericObjectPool which pass and one for > GenericKeyedObjectPool which not pass for same scenario: > {code:java} > @Test > void testGenericKeyedObjectPool() throws Exception { > BaseKeyedPooledObjectFactory baseKeyedPooledObjectFactory = > new BaseKeyedPooledObjectFactory<>() { > @Override > public Object create(String key) throws Exception { > return null; > } > @Override > public PooledObject wrap(Object value) { > return new DefaultPooledObject<>(value); > } > }; > GenericKeyedObjectPoolConfig genericKeyedObjectPoolConfig = new > GenericKeyedObjectPoolConfig<>(); > int minIdlePerKey = 1; > genericKeyedObjectPoolConfig.setMinIdlePerKey(minIdlePerKey); > > genericKeyedObjectPoolConfig.setTimeBetweenEvictionRuns(Duration.ofSeconds(1)); > genericKeyedObjectPoolConfig.setMinEvictableIdleTime(Duration.ofSeconds(5)); > GenericKeyedObjectPool genericKeyedObjectPool = new > GenericKeyedObjectPool<>( > baseKeyedPooledObjectFactory, genericKeyedObjectPoolConfig); > String key = "key"; > genericKeyedObjectPool.preparePool(key); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericKeyedObjectPool.getNumIdle(key) != minIdlePerKey) > ; > }); > System.out.println("we prepared pool so we have idle"); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericKeyedObjectPool.getNumIdle(key) != 0) > ; > }); > System.out.println("after eviction we have no idle"); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericKeyedObjectPool.getNumIdle(key) != minIdlePerKey) > ; > }); > System.out.println("NEVER HAPPEN: after eviction ensure min idle"); > } > @Test > void testGenericObjectPool() throws Exception { > BasePooledObjectFactory basePooledObjectFactory = new > BasePooledObjectFactory<>() { > @Override > public Object create() throws Exception { > return null; > } > @Override > public PooledObject wrap(Object obj) { > return new DefaultPooledObject<>(obj); > } > }; > GenericObjectPoolConfig genericObjectPoolConfig = new > GenericObjectPoolConfig<>(); > int minIdle = 1; > genericObjectPoolConfig.setTimeBetweenEvictionRuns(Duration.ofSeconds(1)); > genericObjectPoolConfig.setMinIdle(minIdle); > genericObjectPoolConfig.setMinEvictableIdleTime(Duration.ofSeconds(5)); > GenericObjectPool genericObjectPool = new > GenericObjectPool<>(basePooledObjectFactory, > genericObjectPoolConfig); > genericObjectPool.preparePool(); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericObjectPool.getNumIdle() != minIdle) > ; > }); > System.out.println("we prepared pool so we have idle"); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericObjectPool.getNumIdle() != 0) > ; > }); > System.out.println("after eviction we have no idle"); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericObjectPool.getNumIdle() != minIdle) > ; > }); > System.out.println("after eviction ensure min idle"); > } > {code} > As workaround I can't just subclass GenericKeyedObjectPool and alter > deregister as it private. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (POOL-412) [GenericKeyedObjectPool] ensureMinIdle not work if last idle evicted
[ https://issues.apache.org/jira/browse/POOL-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729430#comment-17729430 ] Phil Steitz commented on POOL-412: -- This is an interesting use case. Honestly, I think GKOP is working as designed here. There is no contract to maintain an immutable, durable set of keys. Once the last object instance under a key is destroyed, that key no longer exists and ensureMinIdle can't be expected to replenish instances under the key that is no longer there. Admittedly, eviction as the cause of key death is a little extreme, but I can imagine use cases where that is the desired behavior. To "fix" this would require that we keep the key alive which for the OPs use case is desired, but may not be desired in other cases and would have to be extended to failed validations, abandoned objects and all other cases where keyed pools are exhausted. As a workaround for the OP, I would recommend using addObject to restore the keyed pool when it has been removed. I would not recommend changing the GKOP contract to support durable keys. > [GenericKeyedObjectPool] ensureMinIdle not work if last idle evicted > > > Key: POOL-412 > URL: https://issues.apache.org/jira/browse/POOL-412 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.11.1 >Reporter: Oleksandr Porytskyi >Priority: Major > > I'm trying to use GenericKeyedObjectPool with setMinIdlePerKey(1) and > setTestWhileIdle(true). When object failed validation it is removed but > never add new one. > Evictor has two stages: > 1. In evict() call destroy() -> deregister(key) -> poolMap.remove(k) > For some reason it removes key if there are no more objects of it. > > 2. In ensureMinIdle() -> > for (final K k : poolMap.keySet()) { > ensureMinIdle(k); > } > poolMap does not have my key anymore so will not create object for it. > > Here one test for GenericObjectPool which pass and one for > GenericKeyedObjectPool which not pass for same scenario: > {code:java} > @Test > void testGenericKeyedObjectPool() throws Exception { > BaseKeyedPooledObjectFactory baseKeyedPooledObjectFactory = > new BaseKeyedPooledObjectFactory<>() { > @Override > public Object create(String key) throws Exception { > return null; > } > @Override > public PooledObject wrap(Object value) { > return new DefaultPooledObject<>(value); > } > }; > GenericKeyedObjectPoolConfig genericKeyedObjectPoolConfig = new > GenericKeyedObjectPoolConfig<>(); > int minIdlePerKey = 1; > genericKeyedObjectPoolConfig.setMinIdlePerKey(minIdlePerKey); > > genericKeyedObjectPoolConfig.setTimeBetweenEvictionRuns(Duration.ofSeconds(1)); > genericKeyedObjectPoolConfig.setMinEvictableIdleTime(Duration.ofSeconds(5)); > GenericKeyedObjectPool genericKeyedObjectPool = new > GenericKeyedObjectPool<>( > baseKeyedPooledObjectFactory, genericKeyedObjectPoolConfig); > String key = "key"; > genericKeyedObjectPool.preparePool(key); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericKeyedObjectPool.getNumIdle(key) != minIdlePerKey) > ; > }); > System.out.println("we prepared pool so we have idle"); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericKeyedObjectPool.getNumIdle(key) != 0) > ; > }); > System.out.println("after eviction we have no idle"); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericKeyedObjectPool.getNumIdle(key) != minIdlePerKey) > ; > }); > System.out.println("NEVER HAPPEN: after eviction ensure min idle"); > } > @Test > void testGenericObjectPool() throws Exception { > BasePooledObjectFactory basePooledObjectFactory = new > BasePooledObjectFactory<>() { > @Override > public Object create() throws Exception { > return null; > } > @Override > public PooledObject wrap(Object obj) { > return new DefaultPooledObject<>(obj); > } > }; > GenericObjectPoolConfig genericObjectPoolConfig = new > GenericObjectPoolConfig<>(); > int minIdle = 1; > genericObjectPoolConfig.setTimeBetweenEvictionRuns(Duration.ofSeconds(1)); > genericObjectPoolConfig.setMinIdle(minIdle); > genericObjectPoolConfig.setMinEvictableIdleTime(Duration.ofSeconds(5)); > GenericObjectPool genericObjectPool = new > GenericObjectPool<>(basePooledObjectFactory, > genericObjectPoolConfig); > genericObjectPool.preparePool(); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), () -> { > while (genericObjectPool.getNumIdle() != minIdle) > ; > }); > System.out.println("we prepared pool so we have idle"); > Assertions.assertTimeoutPreemptively(Duration.ofMinutes(1), ()
[jira] [Updated] (BCEL-369) org.apache.bcel.verifier.exc.AssertionViolatedException from method return in subroutine
[ https://issues.apache.org/jira/browse/BCEL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Katherine Hough updated BCEL-369: - Attachment: (was: Test.class) > org.apache.bcel.verifier.exc.AssertionViolatedException from method return in > subroutine > > > Key: BCEL-369 > URL: https://issues.apache.org/jira/browse/BCEL-369 > Project: Commons BCEL > Issue Type: Bug > Components: Verifier >Affects Versions: 6.7.0, 6.8.0 >Reporter: Katherine Hough >Priority: Minor > Attachments: Test-1.class > > > Verifier pass 3B fails due to a method return in a subroutine. > There is a comment in the associated code indicating that you are likely > already aware of this issue: > "// TODO: This is buggy, we check only the top-level return instructions this > way. > // Maybe some maniac returns from a method when in a subroutine?" > > The attached class file is what javac for the Java HotSpot SE Development Kit > build 1.4.2_19-b04 produced for the program: > {code:java} > class Test { > public Test(int i) { > try { > i++; > } finally { > if(i == 0) { > return; > } > int u = 7; > u += 9; > } > i++; > } > }{code} > Input: See attached file. > Output: > {code:java} > Apache Commons BCEL > https://commons.apache.org/bcel > Now verifying: Test > Pass 1: > VERIFIED_OK > Passed verification. > Pass 2: > VERIFIED_OK > Passed verification. > Pass 3a, method number 0 ['public void (int arg1)']: > VERIFIED_OK > Passed verification. > Exception in thread "main" > org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: Some > RuntimeException occurred while verify()ing class 'Test', method 'public void > (int arg1)'. Original RuntimeException's stack trace: > --- > org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: > outFrame not set! This: > 24: return [InstructionContext] > ExecutionChain: 24: return [InstructionContext] > OutFrames: '{ 7: jsr -> 19 [InstructionContext]=Local Variables: > 0: Test > 1: int > 2: > 3: 34> > 4: > OperandStack: > Slots used: 0 MaxStack: 1. > , 14: jsr -> 19 [InstructionContext]=Local Variables: > 0: Test > 1: int > 2: java.lang.Throwable > 3: > 4: > OperandStack: > Slots used: 0 MaxStack: 1. > }'. > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.getOutFrame(ControlFlowGraph.java:285) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:275) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > --- > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:398) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > Caused by: org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL > ERROR: outFrame not set! This: > 24: return [InstructionContext] > ExecutionChain: 24: return [InstructionContext] > OutFrames: '{ 7: jsr -> 19 [InstructionContext]=Local Variables: > 0: Test > 1: int > 2: > 3: 34> > 4: > OperandStack: > Slots used: 0 MaxStack: 1. > , 14: jsr -> 19 [InstructionContext]=Local Variables: > 0: Test > 1: int > 2: java.lang.Throwable > 3: > 4: > OperandStack: > Slots used: 0 MaxStack: 1. > }'. > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.getOutFrame(ControlFlowGraph.java:285) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:275) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > ... 4 more > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (BCEL-369) org.apache.bcel.verifier.exc.AssertionViolatedException from method return in subroutine
[ https://issues.apache.org/jira/browse/BCEL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729361#comment-17729361 ] Katherine Hough commented on BCEL-369: -- [^Test.class] I have attached a copy of the class with your suggested class name. The same issue still manifests for git master. I would not expect this issue to occur for a class file created using a newer java compiler because it only manifests when returning from JSR-based local subroutines. My understanding is that JSR instructions are not allowed in Java 7+ class files which is why I used a Java 4 compiler to create a minimal example. This issue would only really be encountered when working with older class files or an older java compiler. > org.apache.bcel.verifier.exc.AssertionViolatedException from method return in > subroutine > > > Key: BCEL-369 > URL: https://issues.apache.org/jira/browse/BCEL-369 > Project: Commons BCEL > Issue Type: Bug > Components: Verifier >Affects Versions: 6.7.0, 6.8.0 >Reporter: Katherine Hough >Priority: Minor > Attachments: Test-1.class, Test.class > > > Verifier pass 3B fails due to a method return in a subroutine. > There is a comment in the associated code indicating that you are likely > already aware of this issue: > "// TODO: This is buggy, we check only the top-level return instructions this > way. > // Maybe some maniac returns from a method when in a subroutine?" > > The attached class file is what javac for the Java HotSpot SE Development Kit > build 1.4.2_19-b04 produced for the program: > {code:java} > class Test { > public Test(int i) { > try { > i++; > } finally { > if(i == 0) { > return; > } > int u = 7; > u += 9; > } > i++; > } > }{code} > Input: See attached file. > Output: > {code:java} > Apache Commons BCEL > https://commons.apache.org/bcel > Now verifying: Test > Pass 1: > VERIFIED_OK > Passed verification. > Pass 2: > VERIFIED_OK > Passed verification. > Pass 3a, method number 0 ['public void (int arg1)']: > VERIFIED_OK > Passed verification. > Exception in thread "main" > org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: Some > RuntimeException occurred while verify()ing class 'Test', method 'public void > (int arg1)'. Original RuntimeException's stack trace: > --- > org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: > outFrame not set! This: > 24: return [InstructionContext] > ExecutionChain: 24: return [InstructionContext] > OutFrames: '{ 7: jsr -> 19 [InstructionContext]=Local Variables: > 0: Test > 1: int > 2: > 3: 34> > 4: > OperandStack: > Slots used: 0 MaxStack: 1. > , 14: jsr -> 19 [InstructionContext]=Local Variables: > 0: Test > 1: int > 2: java.lang.Throwable > 3: > 4: > OperandStack: > Slots used: 0 MaxStack: 1. > }'. > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.getOutFrame(ControlFlowGraph.java:285) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:275) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > --- > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:398) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > Caused by: org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL > ERROR: outFrame not set! This: > 24: return [InstructionContext] > ExecutionChain: 24: return [InstructionContext] > OutFrames: '{ 7: jsr -> 19 [InstructionContext]=Local Variables: > 0: Test > 1: int > 2: > 3: 34> > 4: > OperandStack: > Slots used: 0 MaxStack: 1. > , 14: jsr -> 19 [InstructionContext]=Local Variables: > 0: Test > 1: int > 2: java.lang.Throwable > 3: > 4: > OperandStack: > Slots used: 0 MaxStack: 1. > }'. > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.getOutFrame(ControlFlowGraph.java:285) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVe
[jira] [Updated] (BCEL-369) org.apache.bcel.verifier.exc.AssertionViolatedException from method return in subroutine
[ https://issues.apache.org/jira/browse/BCEL-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Katherine Hough updated BCEL-369: - Attachment: Test-1.class > org.apache.bcel.verifier.exc.AssertionViolatedException from method return in > subroutine > > > Key: BCEL-369 > URL: https://issues.apache.org/jira/browse/BCEL-369 > Project: Commons BCEL > Issue Type: Bug > Components: Verifier >Affects Versions: 6.7.0, 6.8.0 >Reporter: Katherine Hough >Priority: Minor > Attachments: Test-1.class, Test.class > > > Verifier pass 3B fails due to a method return in a subroutine. > There is a comment in the associated code indicating that you are likely > already aware of this issue: > "// TODO: This is buggy, we check only the top-level return instructions this > way. > // Maybe some maniac returns from a method when in a subroutine?" > > The attached class file is what javac for the Java HotSpot SE Development Kit > build 1.4.2_19-b04 produced for the program: > {code:java} > class Test { > public Test(int i) { > try { > i++; > } finally { > if(i == 0) { > return; > } > int u = 7; > u += 9; > } > i++; > } > }{code} > Input: See attached file. > Output: > {code:java} > Apache Commons BCEL > https://commons.apache.org/bcel > Now verifying: Test > Pass 1: > VERIFIED_OK > Passed verification. > Pass 2: > VERIFIED_OK > Passed verification. > Pass 3a, method number 0 ['public void (int arg1)']: > VERIFIED_OK > Passed verification. > Exception in thread "main" > org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: Some > RuntimeException occurred while verify()ing class 'Test', method 'public void > (int arg1)'. Original RuntimeException's stack trace: > --- > org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: > outFrame not set! This: > 24: return [InstructionContext] > ExecutionChain: 24: return [InstructionContext] > OutFrames: '{ 7: jsr -> 19 [InstructionContext]=Local Variables: > 0: Test > 1: int > 2: > 3: 34> > 4: > OperandStack: > Slots used: 0 MaxStack: 1. > , 14: jsr -> 19 [InstructionContext]=Local Variables: > 0: Test > 1: int > 2: java.lang.Throwable > 3: > 4: > OperandStack: > Slots used: 0 MaxStack: 1. > }'. > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.getOutFrame(ControlFlowGraph.java:285) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:275) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > --- > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:398) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > Caused by: org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL > ERROR: outFrame not set! This: > 24: return [InstructionContext] > ExecutionChain: 24: return [InstructionContext] > OutFrames: '{ 7: jsr -> 19 [InstructionContext]=Local Variables: > 0: Test > 1: int > 2: > 3: 34> > 4: > OperandStack: > Slots used: 0 MaxStack: 1. > , 14: jsr -> 19 [InstructionContext]=Local Variables: > 0: Test > 1: int > 2: java.lang.Throwable > 3: > 4: > OperandStack: > Slots used: 0 MaxStack: 1. > }'. > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.getOutFrame(ControlFlowGraph.java:285) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:275) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > ... 4 more > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (BCEL-368) java.lang.StackOverflowError in Select#toString
[ https://issues.apache.org/jira/browse/BCEL-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729352#comment-17729352 ] Katherine Hough commented on BCEL-368: -- [^Test.class] This is a malformed class; I do not have an associated source file. > java.lang.StackOverflowError in Select#toString > --- > > Key: BCEL-368 > URL: https://issues.apache.org/jira/browse/BCEL-368 > Project: Commons BCEL > Issue Type: Bug >Affects Versions: 6.7.0, 6.8.0 >Reporter: Katherine Hough >Priority: Minor > Attachments: Test-1.class, Test.class > > > Select#toString recurses infinitely when there is a self-reference in targets. > Input: See attached file. > Output: > > {code:java} > Apache Commons BCEL > https://commons.apache.org/bcel > Now verifying: Test > Pass 1: > VERIFIED_OK > Passed verification. > Pass 2: > VERIFIED_OK > Passed verification. > Pass 3a, method number 0 ['public static void s()']: > VERIFIED_OK > Passed verification. > Exception in thread "main" java.lang.StackOverflowError > at > java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:828) > at java.base/java.lang.StringBuilder.append(StringBuilder.java:253) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:585) > at > org.apache.bcel.generic.BranchInstruction.toString(BranchInstruction.java:206) > at org.apache.bcel.generic.Select.toString(Select.java:308) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (BCEL-368) java.lang.StackOverflowError in Select#toString
[ https://issues.apache.org/jira/browse/BCEL-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Katherine Hough updated BCEL-368: - Attachment: Test-1.class > java.lang.StackOverflowError in Select#toString > --- > > Key: BCEL-368 > URL: https://issues.apache.org/jira/browse/BCEL-368 > Project: Commons BCEL > Issue Type: Bug >Affects Versions: 6.7.0, 6.8.0 >Reporter: Katherine Hough >Priority: Minor > Attachments: Test-1.class, Test.class > > > Select#toString recurses infinitely when there is a self-reference in targets. > Input: See attached file. > Output: > > {code:java} > Apache Commons BCEL > https://commons.apache.org/bcel > Now verifying: Test > Pass 1: > VERIFIED_OK > Passed verification. > Pass 2: > VERIFIED_OK > Passed verification. > Pass 3a, method number 0 ['public static void s()']: > VERIFIED_OK > Passed verification. > Exception in thread "main" java.lang.StackOverflowError > at > java.base/java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:828) > at java.base/java.lang.StringBuilder.append(StringBuilder.java:253) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:585) > at > org.apache.bcel.generic.BranchInstruction.toString(BranchInstruction.java:206) > at org.apache.bcel.generic.Select.toString(Select.java:308) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > at org.apache.bcel.generic.Instruction.toString(Instruction.java:572) > at org.apache.bcel.generic.Select.toString(Select.java:313) > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (BCEL-367) java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty stack
[ https://issues.apache.org/jira/browse/BCEL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Katherine Hough updated BCEL-367: - Attachment: Test.class > java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty > stack > --- > > Key: BCEL-367 > URL: https://issues.apache.org/jira/browse/BCEL-367 > Project: Commons BCEL > Issue Type: Bug > Components: Verifier >Affects Versions: 6.7.0, 6.8.0 >Reporter: Katherine Hough >Priority: Minor > Attachments: Test.class > > > A java.lang.IndexOutOfBoundsException is thrown when performing verification > pass 3B if the stack is empty before the ATHROW instruction. Expected outcome > is for a verification failure to be reported. > Output: > > {code:java} > Apache Commons BCEL > https://commons.apache.org/bcel > Now verifying: Test > Pass 1: > VERIFIED_OK > Passed verification. > Pass 2: > VERIFIED_OK > Passed verification. > Pass 3a, method number 0 ['static void x()']: > VERIFIED_OK > Passed verification. > Exception in thread "main" > org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: Some > RuntimeException occurred while verify()ing class 'Test', method 'static void > x()'. Original RuntimeException's stack trace: > --- > java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > --- > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:398) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > Caused by: java.lang.IndexOutOfBoundsException: Index -1 out of bounds for > length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > ... 4 more > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (BCEL-367) java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty stack
[ https://issues.apache.org/jira/browse/BCEL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Katherine Hough updated BCEL-367: - Attachment: (was: Test.class) > java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty > stack > --- > > Key: BCEL-367 > URL: https://issues.apache.org/jira/browse/BCEL-367 > Project: Commons BCEL > Issue Type: Bug > Components: Verifier >Affects Versions: 6.7.0, 6.8.0 >Reporter: Katherine Hough >Priority: Minor > Attachments: Test.class > > > A java.lang.IndexOutOfBoundsException is thrown when performing verification > pass 3B if the stack is empty before the ATHROW instruction. Expected outcome > is for a verification failure to be reported. > Output: > > {code:java} > Apache Commons BCEL > https://commons.apache.org/bcel > Now verifying: Test > Pass 1: > VERIFIED_OK > Passed verification. > Pass 2: > VERIFIED_OK > Passed verification. > Pass 3a, method number 0 ['static void x()']: > VERIFIED_OK > Passed verification. > Exception in thread "main" > org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: Some > RuntimeException occurred while verify()ing class 'Test', method 'static void > x()'. Original RuntimeException's stack trace: > --- > java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > --- > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:398) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > Caused by: java.lang.IndexOutOfBoundsException: Index -1 out of bounds for > length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > ... 4 more > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (BCEL-367) java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty stack
[ https://issues.apache.org/jira/browse/BCEL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729349#comment-17729349 ] Katherine Hough commented on BCEL-367: -- [^Test.class] This is the smallest example I could make. > java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty > stack > --- > > Key: BCEL-367 > URL: https://issues.apache.org/jira/browse/BCEL-367 > Project: Commons BCEL > Issue Type: Bug > Components: Verifier >Affects Versions: 6.7.0, 6.8.0 >Reporter: Katherine Hough >Priority: Minor > Attachments: Test.class > > > A java.lang.IndexOutOfBoundsException is thrown when performing verification > pass 3B if the stack is empty before the ATHROW instruction. Expected outcome > is for a verification failure to be reported. > Output: > > {code:java} > Apache Commons BCEL > https://commons.apache.org/bcel > Now verifying: Test > Pass 1: > VERIFIED_OK > Passed verification. > Pass 2: > VERIFIED_OK > Passed verification. > Pass 3a, method number 0 ['static void x()']: > VERIFIED_OK > Passed verification. > Exception in thread "main" > org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: Some > RuntimeException occurred while verify()ing class 'Test', method 'static void > x()'. Original RuntimeException's stack trace: > --- > java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > --- > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:398) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > Caused by: java.lang.IndexOutOfBoundsException: Index -1 out of bounds for > length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > ... 4 more > {code} > -- This message was sent by Atlassian Jira (v8.20.10#8
[jira] [Updated] (BCEL-367) java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty stack
[ https://issues.apache.org/jira/browse/BCEL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Katherine Hough updated BCEL-367: - Attachment: (was: Test-1.class) > java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty > stack > --- > > Key: BCEL-367 > URL: https://issues.apache.org/jira/browse/BCEL-367 > Project: Commons BCEL > Issue Type: Bug > Components: Verifier >Affects Versions: 6.7.0, 6.8.0 >Reporter: Katherine Hough >Priority: Minor > Attachments: Test.class > > > A java.lang.IndexOutOfBoundsException is thrown when performing verification > pass 3B if the stack is empty before the ATHROW instruction. Expected outcome > is for a verification failure to be reported. > Output: > > {code:java} > Apache Commons BCEL > https://commons.apache.org/bcel > Now verifying: Test > Pass 1: > VERIFIED_OK > Passed verification. > Pass 2: > VERIFIED_OK > Passed verification. > Pass 3a, method number 0 ['static void x()']: > VERIFIED_OK > Passed verification. > Exception in thread "main" > org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: Some > RuntimeException occurred while verify()ing class 'Test', method 'static void > x()'. Original RuntimeException's stack trace: > --- > java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > --- > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:398) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > Caused by: java.lang.IndexOutOfBoundsException: Index -1 out of bounds for > length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > ... 4 more > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (BCEL-367) java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty stack
[ https://issues.apache.org/jira/browse/BCEL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729348#comment-17729348 ] Katherine Hough edited comment on BCEL-367 at 6/5/23 2:49 PM: -- ^This is the smallest example I could make.^ was (Author: JIRAUSER300711): [^Test.class] ^This is the smallest example I could make.^ > java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty > stack > --- > > Key: BCEL-367 > URL: https://issues.apache.org/jira/browse/BCEL-367 > Project: Commons BCEL > Issue Type: Bug > Components: Verifier >Affects Versions: 6.7.0, 6.8.0 >Reporter: Katherine Hough >Priority: Minor > Attachments: Test-1.class, Test.class > > > A java.lang.IndexOutOfBoundsException is thrown when performing verification > pass 3B if the stack is empty before the ATHROW instruction. Expected outcome > is for a verification failure to be reported. > Output: > > {code:java} > Apache Commons BCEL > https://commons.apache.org/bcel > Now verifying: Test > Pass 1: > VERIFIED_OK > Passed verification. > Pass 2: > VERIFIED_OK > Passed verification. > Pass 3a, method number 0 ['static void x()']: > VERIFIED_OK > Passed verification. > Exception in thread "main" > org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: Some > RuntimeException occurred while verify()ing class 'Test', method 'static void > x()'. Original RuntimeException's stack trace: > --- > java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > --- > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:398) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > Caused by: java.lang.IndexOutOfBoundsException: Index -1 out of bounds for > length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structur
[jira] (BCEL-367) java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty stack
[ https://issues.apache.org/jira/browse/BCEL-367 ] Katherine Hough deleted comment on BCEL-367: -- was (Author: JIRAUSER300711): ^This is the smallest example I could make.^ > java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty > stack > --- > > Key: BCEL-367 > URL: https://issues.apache.org/jira/browse/BCEL-367 > Project: Commons BCEL > Issue Type: Bug > Components: Verifier >Affects Versions: 6.7.0, 6.8.0 >Reporter: Katherine Hough >Priority: Minor > Attachments: Test-1.class, Test.class > > > A java.lang.IndexOutOfBoundsException is thrown when performing verification > pass 3B if the stack is empty before the ATHROW instruction. Expected outcome > is for a verification failure to be reported. > Output: > > {code:java} > Apache Commons BCEL > https://commons.apache.org/bcel > Now verifying: Test > Pass 1: > VERIFIED_OK > Passed verification. > Pass 2: > VERIFIED_OK > Passed verification. > Pass 3a, method number 0 ['static void x()']: > VERIFIED_OK > Passed verification. > Exception in thread "main" > org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: Some > RuntimeException occurred while verify()ing class 'Test', method 'static void > x()'. Original RuntimeException's stack trace: > --- > java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > --- > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:398) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > Caused by: java.lang.IndexOutOfBoundsException: Index -1 out of bounds for > length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > ... 4 more > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (BCEL-367) java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty stack
[ https://issues.apache.org/jira/browse/BCEL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729348#comment-17729348 ] Katherine Hough commented on BCEL-367: -- [^Test.class] ^This is the smallest example I could make.^ > java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty > stack > --- > > Key: BCEL-367 > URL: https://issues.apache.org/jira/browse/BCEL-367 > Project: Commons BCEL > Issue Type: Bug > Components: Verifier >Affects Versions: 6.7.0, 6.8.0 >Reporter: Katherine Hough >Priority: Minor > Attachments: Test-1.class, Test.class > > > A java.lang.IndexOutOfBoundsException is thrown when performing verification > pass 3B if the stack is empty before the ATHROW instruction. Expected outcome > is for a verification failure to be reported. > Output: > > {code:java} > Apache Commons BCEL > https://commons.apache.org/bcel > Now verifying: Test > Pass 1: > VERIFIED_OK > Passed verification. > Pass 2: > VERIFIED_OK > Passed verification. > Pass 3a, method number 0 ['static void x()']: > VERIFIED_OK > Passed verification. > Exception in thread "main" > org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: Some > RuntimeException occurred while verify()ing class 'Test', method 'static void > x()'. Original RuntimeException's stack trace: > --- > java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > --- > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:398) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > Caused by: java.lang.IndexOutOfBoundsException: Index -1 out of bounds for > length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > ... 4 more > {code} > -- This message was sent by Atlassian
[jira] [Updated] (BCEL-367) java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty stack
[ https://issues.apache.org/jira/browse/BCEL-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Katherine Hough updated BCEL-367: - Attachment: Test-1.class > java.lang.IndexOutOfBoundsException thrown for an ATHROW instruction on empty > stack > --- > > Key: BCEL-367 > URL: https://issues.apache.org/jira/browse/BCEL-367 > Project: Commons BCEL > Issue Type: Bug > Components: Verifier >Affects Versions: 6.7.0, 6.8.0 >Reporter: Katherine Hough >Priority: Minor > Attachments: Test-1.class, Test.class > > > A java.lang.IndexOutOfBoundsException is thrown when performing verification > pass 3B if the stack is empty before the ATHROW instruction. Expected outcome > is for a verification failure to be reported. > Output: > > {code:java} > Apache Commons BCEL > https://commons.apache.org/bcel > Now verifying: Test > Pass 1: > VERIFIED_OK > Passed verification. > Pass 2: > VERIFIED_OK > Passed verification. > Pass 3a, method number 0 ['static void x()']: > VERIFIED_OK > Passed verification. > Exception in thread "main" > org.apache.bcel.verifier.exc.AssertionViolatedException: INTERNAL ERROR: Some > RuntimeException occurred while verify()ing class 'Test', method 'static void > x()'. Original RuntimeException's stack trace: > --- > java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > --- > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:398) > at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:98) > at org.apache.bcel.verifier.Verifier.doPass3b(Verifier.java:166) > at org.apache.bcel.verifier.Verifier.verifyType(Verifier.java:90) > at org.apache.bcel.verifier.Verifier.main(Verifier.java:69) > Caused by: java.lang.IndexOutOfBoundsException: Index -1 out of bounds for > length 0 > at > java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) > at > java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) > at > java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) > at java.base/java.util.Objects.checkIndex(Objects.java:361) > at java.base/java.util.ArrayList.get(ArrayList.java:427) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:180) > at > org.apache.bcel.verifier.structurals.OperandStack.peek(OperandStack.java:172) > at > org.apache.bcel.verifier.structurals.InstConstraintVisitor.visitATHROW(InstConstraintVisitor.java:317) > at org.apache.bcel.generic.ATHROW.accept(ATHROW.java:47) > at > org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:84) > at > org.apache.bcel.verifier.structurals.ControlFlowGraph$InstructionContextImpl.execute(ControlFlowGraph.java:198) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.circulationPump(Pass3bVerifier.java:164) > at > org.apache.bcel.verifier.structurals.Pass3bVerifier.do_verify(Pass3bVerifier.java:386) > ... 4 more > {code} > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-bcel] gabibguti commented on pull request #224: Reference actions by commit SHA
gabibguti commented on PR #224: URL: https://github.com/apache/commons-bcel/pull/224#issuecomment-1576920408 > > Hi @gabibguti Thank you for the PR. Will dependabot be able to update versions? > > Hm, looks like it does! For example: https://github.com/apache/commons-lang/blame/ebcb39a62fc1e47251eceaf63a4b3d731c5227a0/.github/workflows/maven.yml Hi @garydgregory ! Yes, [dependabot is able to update both the commit SHA and the comment with the semantic version](https://github.blog/changelog/2022-10-31-dependabot-now-updates-comments-in-github-actions-workflows-referencing-action-versions/). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] sebbASF commented on pull request #389: Change source encoding to UTF-8
sebbASF commented on PR #389: URL: https://github.com/apache/commons-compress/pull/389#issuecomment-1576896714 I can confirm that changing the encoding causes the compile to report an ERROR, but the build succeeds: $ mvn clean compile -Dcommons.encoding=UTF8 ... [INFO] Compiling 399 source files with javac [debug release 8] to target/classes [ERROR] /commons/compress/src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveOutputStream.java:[300,32] unmappable character (0xF6) for encoding UTF-8 ... [INFO] BUILD SUCCESS I've tried experimenting with -Dmaven.compiler.failOnWarning=true (and failOnError), but Maven does not fail the build. However, adding -Dcommons.compiler.fork=true does cause the build to fail. Possible bug in Maven? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] mkoncek commented on pull request #389: Change source encoding to UTF-8
mkoncek commented on PR #389: URL: https://github.com/apache/commons-compress/pull/389#issuecomment-1576651634 maven-compiler-plugin is declared in `commons-parent` which also uses the `encoding` field. I rebased the PR so that the build reports an error the same way as `javac` would in our case. I don't know why the build doesn't fail, but there is an `[ERROR]` in the log if encoding is set and current sources are used. `commons-parent` uses ISO-8859 encoding by default. @sebbASF That would work too, but I believe it is time we can afford such luxury as using non-ASCII-only characters in sources. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DAEMON-460) High CPU usage in prunsrv.exe since Daemon 1.3.4
[ https://issues.apache.org/jira/browse/DAEMON-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729291#comment-17729291 ] Japie vd Linde commented on DAEMON-460: --- Hi [~markt] That is correct, there is no problem on 1.3.2 (apache daemon JAR 1.3.2 and amd64 prunsrv.exe that goes with version 1.3.2). !image-2023-06-05-13-38-38-435.png! > High CPU usage in prunsrv.exe since Daemon 1.3.4 > > > Key: DAEMON-460 > URL: https://issues.apache.org/jira/browse/DAEMON-460 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.3.3 >Reporter: Japie vd Linde >Priority: Major > Attachments: EspRun-Service-Log.2023-06-05.log, > image-2023-05-31-09-31-21-485.png, image-2023-06-05-13-38-38-435.png > > > When using the --StopTimeout=30 parameter on service using prunsrv the CPU > usage is reported as very high on Windows. Rolling back to older prunsrv > seems to resolve the problem. > !image-2023-05-31-09-31-21-485.png! > What could be the possible causes for this problem? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DAEMON-460) High CPU usage in prunsrv.exe since Daemon 1.3.3
[ https://issues.apache.org/jira/browse/DAEMON-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Japie vd Linde updated DAEMON-460: -- Summary: High CPU usage in prunsrv.exe since Daemon 1.3.3 (was: High CPU usage in prunsrv.exe since Daemon 1.3.4) > High CPU usage in prunsrv.exe since Daemon 1.3.3 > > > Key: DAEMON-460 > URL: https://issues.apache.org/jira/browse/DAEMON-460 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.3.3 >Reporter: Japie vd Linde >Priority: Major > Attachments: EspRun-Service-Log.2023-06-05.log, > image-2023-05-31-09-31-21-485.png, image-2023-06-05-13-38-38-435.png > > > When using the --StopTimeout=30 parameter on service using prunsrv the CPU > usage is reported as very high on Windows. Rolling back to older prunsrv > seems to resolve the problem. > !image-2023-05-31-09-31-21-485.png! > What could be the possible causes for this problem? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DAEMON-460) High CPU usage in prunsrv.exe since Daemon 1.3.4
[ https://issues.apache.org/jira/browse/DAEMON-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Japie vd Linde updated DAEMON-460: -- Attachment: image-2023-06-05-13-38-38-435.png > High CPU usage in prunsrv.exe since Daemon 1.3.4 > > > Key: DAEMON-460 > URL: https://issues.apache.org/jira/browse/DAEMON-460 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.3.3 >Reporter: Japie vd Linde >Priority: Major > Attachments: EspRun-Service-Log.2023-06-05.log, > image-2023-05-31-09-31-21-485.png, image-2023-06-05-13-38-38-435.png > > > When using the --StopTimeout=30 parameter on service using prunsrv the CPU > usage is reported as very high on Windows. Rolling back to older prunsrv > seems to resolve the problem. > !image-2023-05-31-09-31-21-485.png! > What could be the possible causes for this problem? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DAEMON-460) High CPU usage in prunsrv.exe since Daemon 1.3.4
[ https://issues.apache.org/jira/browse/DAEMON-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729285#comment-17729285 ] Mark Thomas commented on DAEMON-460: Have you explicitly tested this with 1.3.2 and confirmed that 1.3.2 does not exhibit this behaviour? > High CPU usage in prunsrv.exe since Daemon 1.3.4 > > > Key: DAEMON-460 > URL: https://issues.apache.org/jira/browse/DAEMON-460 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.3.3 >Reporter: Japie vd Linde >Priority: Major > Attachments: EspRun-Service-Log.2023-06-05.log, > image-2023-05-31-09-31-21-485.png > > > When using the --StopTimeout=30 parameter on service using prunsrv the CPU > usage is reported as very high on Windows. Rolling back to older prunsrv > seems to resolve the problem. > !image-2023-05-31-09-31-21-485.png! > What could be the possible causes for this problem? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-compress] sebbASF commented on a diff in pull request #389: Change source encoding to UTF-8
sebbASF commented on code in PR #389: URL: https://github.com/apache/commons-compress/pull/389#discussion_r1217913999 ## src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveOutputStream.java: ## @@ -297,7 +297,7 @@ private void addPaxHeadersForBigNumbers(final Map paxHeaders, TarConstants.MAXID); // libarchive extensions addFileTimePaxHeader(paxHeaders, "LIBARCHIVE.creationtime", entry.getCreationTime()); -// star extensions by J�rg Schilling +// star extensions by Jörg Schilling Review Comment: Could also use: // star extensions by Joerg Schilling -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DAEMON-460) High CPU usage in prunsrv.exe since Daemon 1.3.4
[ https://issues.apache.org/jira/browse/DAEMON-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729280#comment-17729280 ] Japie vd Linde commented on DAEMON-460: --- Hi [~ggregory] I have done some more testing. This issue (having higher CPU/power usage) occurs since 1.3.3, as I observed on both 1.3.3 and 1.3.4 so I corrected the affected version. Before that it was using significant less problems. I have tested with 2 different test applications. I couldn't see any further messages with the following debug parameters enabled --LogLevel=Debug --LogJniMessages=1 [^EspRun-Service-Log.2023-06-05.log] > High CPU usage in prunsrv.exe since Daemon 1.3.4 > > > Key: DAEMON-460 > URL: https://issues.apache.org/jira/browse/DAEMON-460 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.3.3 >Reporter: Japie vd Linde >Priority: Major > Attachments: EspRun-Service-Log.2023-06-05.log, > image-2023-05-31-09-31-21-485.png > > > When using the --StopTimeout=30 parameter on service using prunsrv the CPU > usage is reported as very high on Windows. Rolling back to older prunsrv > seems to resolve the problem. > !image-2023-05-31-09-31-21-485.png! > What could be the possible causes for this problem? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DAEMON-460) High CPU usage in prunsrv.exe since Daemon 1.3.4
[ https://issues.apache.org/jira/browse/DAEMON-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Japie vd Linde updated DAEMON-460: -- Attachment: EspRun-Service-Log.2023-06-05.log > High CPU usage in prunsrv.exe since Daemon 1.3.4 > > > Key: DAEMON-460 > URL: https://issues.apache.org/jira/browse/DAEMON-460 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.3.3 >Reporter: Japie vd Linde >Priority: Major > Attachments: EspRun-Service-Log.2023-06-05.log, > image-2023-05-31-09-31-21-485.png > > > When using the --StopTimeout=30 parameter on service using prunsrv the CPU > usage is reported as very high on Windows. Rolling back to older prunsrv > seems to resolve the problem. > !image-2023-05-31-09-31-21-485.png! > What could be the possible causes for this problem? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DAEMON-460) High CPU usage in prunsrv.exe since Daemon 1.3.4
[ https://issues.apache.org/jira/browse/DAEMON-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729274#comment-17729274 ] Gary D. Gregory commented on DAEMON-460: Note: The version affected was just changed from 1.3.4 to 1.3.3. > High CPU usage in prunsrv.exe since Daemon 1.3.4 > > > Key: DAEMON-460 > URL: https://issues.apache.org/jira/browse/DAEMON-460 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.3.3 >Reporter: Japie vd Linde >Priority: Major > Attachments: image-2023-05-31-09-31-21-485.png > > > When using the --StopTimeout=30 parameter on service using prunsrv the CPU > usage is reported as very high on Windows. Rolling back to older prunsrv > seems to resolve the problem. > !image-2023-05-31-09-31-21-485.png! > What could be the possible causes for this problem? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-compress] garydgregory commented on pull request #389: Change source encoding to UTF-8
garydgregory commented on PR #389: URL: https://github.com/apache/commons-compress/pull/389#issuecomment-1576576537 Hello @mkoncek How can this goal be enforced such that this build fails without the change? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (DAEMON-460) High CPU usage in prunsrv.exe since Daemon 1.3.4
[ https://issues.apache.org/jira/browse/DAEMON-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Japie vd Linde updated DAEMON-460: -- Affects Version/s: 1.3.3 (was: 1.3.4) > High CPU usage in prunsrv.exe since Daemon 1.3.4 > > > Key: DAEMON-460 > URL: https://issues.apache.org/jira/browse/DAEMON-460 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.3.3 >Reporter: Japie vd Linde >Priority: Major > Attachments: image-2023-05-31-09-31-21-485.png > > > When using the --StopTimeout=30 parameter on service using prunsrv the CPU > usage is reported as very high on Windows. Rolling back to older prunsrv > seems to resolve the problem. > !image-2023-05-31-09-31-21-485.png! > What could be the possible causes for this problem? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-compress] mkoncek opened a new pull request, #389: Change source encoding to UTF-8
mkoncek opened a new pull request, #389: URL: https://github.com/apache/commons-compress/pull/389 We have a project which bootstraps Maven. It manually calls `javac` and we encountered a problem with source encoding. I would like to unify source encodings to UTF-8. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org