[jira] [Created] (MATH-1375) BOBYQAOptimizer Seems to Sometimes Enter Endless Loop
Thomas Weise created MATH-1375:
--
Summary: BOBYQAOptimizer Seems to Sometimes Enter Endless Loop
Key: MATH-1375
URL: https://issues.apache.org/jira/browse/MATH-1375
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.6.1
Environment: Java 8 JDK, OpenJDK, Ubuntu
Reporter: Thomas Weise
Priority: Minor
I am using BOBYQAOptimizer to solve some numerical problems related to
nonlinear function fitting. BOBYQAOptimizer is provided with close-to-optimal
solutions which it is supposed to refine. In some cases, BOBYQAOptimizer seems
to enter an endless loop, or at least an extremely long loop. The problem is
almost impossible to reproduce as it occurs maybe once every 1000 runs.
>From what I can see with the debugger, the source of the problem is probably
>method trsbox which is called by bobyqb. In trsbox, some values of a vector
>(sorry, forgot which one) grow extremely large (>=1e250). Either way, I
>noticed that both mentioned methods feature a for(;;) loop.
Now that algorithm looks quite mathematical to me and seemingly has been
translated from FORTRAN or something. I think fixing and finding mathematical
issues might be complicated (see also the caveats reported in the release
notes) and overall, the algorithm is working.
How about you also count the iterations of the for(;;) loops in bobyqb and
trsbox and throw an exception if they exceed some limit? In the easiest case,
instead of for(;;) you can do something like
for(int maxRemainingSteps=100; (--maxRemainingSteps)>=0;) {
...
}
throw new MaxCountExceededException(100);
// or TooManyEvaluationsException(100);
// or MathIllegalStateException(LocalizedFormats.SIMPLE_MESSAGE, "Huh?");
Since the original for loops are always left via "return", that would already
do the trick. Or you could use an Incrementor object for this purpose. Either
way, I think with the very simple fix above, you would prevent endless loops,
add only a tiny bit of very easy-to-understand code, and would not break the
algorithm contract, since such exceptions could be thrown sometimes even
without the fix.
In summary: BOBYQAOptimizer needs some work. Fixing the issue I observed
properly (i.e., by fixing the special cases causing it) is probably very
complex and is probably not feasible. Preventing it, however, seems to be
rather easy, as I have shown above.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MATH-1373) In LogNormalDistribution.java, it appears shape & scale are reversed/mis-labelled.
[ https://issues.apache.org/jira/browse/MATH-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15321625#comment-15321625 ] Gilles commented on MATH-1373: -- Since there are many tests for this class, I wonder what the problem is. Is it a documentation bug? Would you provide a patch that would fix the issue? > In LogNormalDistribution.java, it appears shape & scale are > reversed/mis-labelled. > -- > > Key: MATH-1373 > URL: https://issues.apache.org/jira/browse/MATH-1373 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Karl D. Gierach >Priority: Minor > Original Estimate: 1h > Remaining Estimate: 1h > > When I compute the logshape and log scale based on the formulas on > wikipedia's lognormal distribution page that use empirical mean and variance, > I found that the getNumericalMean() method was not returning the empirical > mean. > However, upon just trying to reverse the shape and scale parameters in the > constructor proved to fix the problem, and the object then returns the > correct empirical mean. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-500) VFSClassLoader.findResources missing
[
https://issues.apache.org/jira/browse/VFS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15321547#comment-15321547
]
Bernd Eckenfels commented on VFS-500:
-
I am running "mvn -Pinclude-sandbox -U clean install" successfully on Win7x64
(de) with 1747457.2.2-SNAPSHOT (r1747457).
{quote}
Maven 3.2.5
Java(TM) SE Runtime Environment (build pwa6470sr6-20131015_01(SR6))
IBM J9 VM (build 2.6, JRE 1.7.0 Windows 7 amd64-64 Compressed References
20131013_170512 (JIT enabled, AOT enabled)
Tests run: 2138, Failures: 0, Errors: 0, Skipped: 2
{quote}
as well as
{quote}
Maven 3.2.5
Java(TM) SE Runtime Environment (build pwa6480sr3-20160428_01(SR3))
IBM J9 VM (build 2.8, JRE 1.8.0 Windows 7 amd64-64 Compressed References
20160427_301573 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR3_20160427_1620_B301573
...
JCL - 20160421_01 based on Oracle jdk8u91-b14
Tests run: 2138, Failures: 0, Errors: 0, Skipped: 2
{quote}
Joerg, do you try Linux or AIX? Which assertion fails?
> VFSClassLoader.findResources missing
>
>
> Key: VFS-500
> URL: https://issues.apache.org/jira/browse/VFS-500
> Project: Commons VFS
> Issue Type: New Feature
>Affects Versions: 2.0
>Reporter: Bernd Eckenfels
>Assignee: Bernd Eckenfels
>Priority: Minor
> Fix For: 2.2
>
> Attachments: vfs-500-gg.diff
>
>
> the VFSClassLoader.findResources(String) method is a dummy implementation
> returning an empty Enumeration.
> I have a working implementation and will support the patch for it, this is
> the JIRA to track it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LANG-1229) Performance regression due to cyclic hashCode guard
[ https://issues.apache.org/jira/browse/LANG-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed LANG-1229. --- Resolution: Fixed Assignee: Pascal Schumacher Fix Version/s: 3.5 > Performance regression due to cyclic hashCode guard > --- > > Key: LANG-1229 > URL: https://issues.apache.org/jira/browse/LANG-1229 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 3.5 >Reporter: Philippe Marschall >Assignee: Pascal Schumacher > Fix For: 3.5 > > > We observed a severe performance regression in HashCodeBuilder in 3.5 trunk > compared to 3.4 release. We get about 20% of the throughput in 3.5 trunk for > common cases compared to 3.4 release. Previously there was no noticeable > overhead of using HashCodeBuilder. Investigating we found the performance > degradation was caused by the fix for LANG-456. It causes the method to be > too large to be inlined and escape analysis to fail (see LANG-1218 for a > related discussion). > We currently do not see a way to keep the 3.4 performance and support cyclic > graphs. The append methods have not supported cycles for so long we feel it's > de facto part of the contract by now. Since neither the JDK nor the Guava > hashCode helper methods support cyclic graphs we don't believe this is an > unreasonable assumption. In addition EqualsBuilder#append(Object,Object) > doesn't support cycles. > If supporting cycles is a requirement we propose the introduction of new > #appendRecursive (or named differently) methods to both HashCodeBuilder and > EqualsBuilder that add cycle guards. If that is an acceptable compromise we > would be willing to provide patches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1229) Performance regression due to cyclic hashCode guard
[ https://issues.apache.org/jira/browse/LANG-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15321391#comment-15321391 ] Pascal Schumacher commented on LANG-1229: - Pull request applied. Thanks. I reopened LANG-456. > Performance regression due to cyclic hashCode guard > --- > > Key: LANG-1229 > URL: https://issues.apache.org/jira/browse/LANG-1229 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 3.5 >Reporter: Philippe Marschall > > We observed a severe performance regression in HashCodeBuilder in 3.5 trunk > compared to 3.4 release. We get about 20% of the throughput in 3.5 trunk for > common cases compared to 3.4 release. Previously there was no noticeable > overhead of using HashCodeBuilder. Investigating we found the performance > degradation was caused by the fix for LANG-456. It causes the method to be > too large to be inlined and escape analysis to fail (see LANG-1218 for a > related discussion). > We currently do not see a way to keep the 3.4 performance and support cyclic > graphs. The append methods have not supported cycles for so long we feel it's > de facto part of the contract by now. Since neither the JDK nor the Guava > hashCode helper methods support cyclic graphs we don't believe this is an > unreasonable assumption. In addition EqualsBuilder#append(Object,Object) > doesn't support cycles. > If supporting cycles is a requirement we propose the introduction of new > #appendRecursive (or named differently) methods to both HashCodeBuilder and > EqualsBuilder that add cycle guards. If that is an acceptable compromise we > would be willing to provide patches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-456) HashCodeBuilder throws StackOverflowError in bidirectional navigable association
[ https://issues.apache.org/jira/browse/LANG-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher updated LANG-456: --- Fix Version/s: (was: 3.5) > HashCodeBuilder throws StackOverflowError in bidirectional navigable > association > > > Key: LANG-456 > URL: https://issues.apache.org/jira/browse/LANG-456 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 2.4 > Environment: Widows XP. Sun JDK 1.5 or 1.6. >Reporter: Bob Fields > Attachments: > 0001-LANG-456-HashCodeBuilder-throws-StackOverflowError-i.patch, > HashCodeBuilderStackOverflow.zip, LANG-456-patch.txt, StackOverflowError.zip > > > This is not the reflection methods, it is the regular HashCodeBuilder append > methods. It causes EqualsBuilder, ToStringBuilder, CompareToBuilder to also > throw the StackOverflowException, but those methods work when one of the > HashCodeBuilder bidirectional association attributes .hashCode() is commented > out. The problem is that all of the builders call registerObject() which > creates a hashCode, but only the reflectionAppend method checks if an object > is registered. > Bi-directional associations are a very common pattern in Jaxb and Hibernate. > In this case, I generate code from a model in order to avoid the reflection > penalty - I already know what the attributes are at compile time, so I use > .append instead of .reflectionAppend. > See attached example + unit test. One side of the bidirectional association > must be commented out in the hashCode method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (LANG-456) HashCodeBuilder throws StackOverflowError in bidirectional navigable association
[ https://issues.apache.org/jira/browse/LANG-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher reopened LANG-456: Assignee: (was: Benedikt Ritter) I reverted the commit because it caused LANG-1229. I believe we can not justify a major performance regression to add this feature. The best approach would be to add a new method that appends with the check (see discussion of LANG-1229). > HashCodeBuilder throws StackOverflowError in bidirectional navigable > association > > > Key: LANG-456 > URL: https://issues.apache.org/jira/browse/LANG-456 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 2.4 > Environment: Widows XP. Sun JDK 1.5 or 1.6. >Reporter: Bob Fields > Attachments: > 0001-LANG-456-HashCodeBuilder-throws-StackOverflowError-i.patch, > HashCodeBuilderStackOverflow.zip, LANG-456-patch.txt, StackOverflowError.zip > > > This is not the reflection methods, it is the regular HashCodeBuilder append > methods. It causes EqualsBuilder, ToStringBuilder, CompareToBuilder to also > throw the StackOverflowException, but those methods work when one of the > HashCodeBuilder bidirectional association attributes .hashCode() is commented > out. The problem is that all of the builders call registerObject() which > creates a hashCode, but only the reflectionAppend method checks if an object > is registered. > Bi-directional associations are a very common pattern in Jaxb and Hibernate. > In this case, I generate code from a model in order to avoid the reflection > penalty - I already know what the attributes are at compile time, so I use > .append instead of .reflectionAppend. > See attached example + unit test. One side of the bidirectional association > must be commented out in the hashCode method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1229) Performance regression due to cyclic hashCode guard
[ https://issues.apache.org/jira/browse/LANG-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15321385#comment-15321385 ] ASF GitHub Bot commented on LANG-1229: -- Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/142 Thanks! :+1: > Performance regression due to cyclic hashCode guard > --- > > Key: LANG-1229 > URL: https://issues.apache.org/jira/browse/LANG-1229 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 3.5 >Reporter: Philippe Marschall > > We observed a severe performance regression in HashCodeBuilder in 3.5 trunk > compared to 3.4 release. We get about 20% of the throughput in 3.5 trunk for > common cases compared to 3.4 release. Previously there was no noticeable > overhead of using HashCodeBuilder. Investigating we found the performance > degradation was caused by the fix for LANG-456. It causes the method to be > too large to be inlined and escape analysis to fail (see LANG-1218 for a > related discussion). > We currently do not see a way to keep the 3.4 performance and support cyclic > graphs. The append methods have not supported cycles for so long we feel it's > de facto part of the contract by now. Since neither the JDK nor the Guava > hashCode helper methods support cyclic graphs we don't believe this is an > unreasonable assumption. In addition EqualsBuilder#append(Object,Object) > doesn't support cycles. > If supporting cycles is a requirement we propose the introduction of new > #appendRecursive (or named differently) methods to both HashCodeBuilder and > EqualsBuilder that add cycle guards. If that is an acceptable compromise we > would be willing to provide patches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1229) Performance regression due to cyclic hashCode guard
[ https://issues.apache.org/jira/browse/LANG-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15321384#comment-15321384 ] ASF GitHub Bot commented on LANG-1229: -- Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/142 > Performance regression due to cyclic hashCode guard > --- > > Key: LANG-1229 > URL: https://issues.apache.org/jira/browse/LANG-1229 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 3.5 >Reporter: Philippe Marschall > > We observed a severe performance regression in HashCodeBuilder in 3.5 trunk > compared to 3.4 release. We get about 20% of the throughput in 3.5 trunk for > common cases compared to 3.4 release. Previously there was no noticeable > overhead of using HashCodeBuilder. Investigating we found the performance > degradation was caused by the fix for LANG-456. It causes the method to be > too large to be inlined and escape analysis to fail (see LANG-1218 for a > related discussion). > We currently do not see a way to keep the 3.4 performance and support cyclic > graphs. The append methods have not supported cycles for so long we feel it's > de facto part of the contract by now. Since neither the JDK nor the Guava > hashCode helper methods support cyclic graphs we don't believe this is an > unreasonable assumption. In addition EqualsBuilder#append(Object,Object) > doesn't support cycles. > If supporting cycles is a requirement we propose the introduction of new > #appendRecursive (or named differently) methods to both HashCodeBuilder and > EqualsBuilder that add cycle guards. If that is an acceptable compromise we > would be willing to provide patches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] commons-lang issue #142: LANG-1229 Performance regression in HashCodeBuilder
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/142 Thanks! :+1: --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang pull request #142: LANG-1229 Performance regression in HashCode...
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/142 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (VFS-500) VFSClassLoader.findResources missing
[ https://issues.apache.org/jira/browse/VFS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15321215#comment-15321215 ] Joerg Schaible commented on VFS-500: The fix seemed to cure Jenkins, but the IBM JDK still fails with the same error like Jenkins before. > VFSClassLoader.findResources missing > > > Key: VFS-500 > URL: https://issues.apache.org/jira/browse/VFS-500 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Bernd Eckenfels >Assignee: Bernd Eckenfels >Priority: Minor > Fix For: 2.2 > > Attachments: vfs-500-gg.diff > > > the VFSClassLoader.findResources(String) method is a dummy implementation > returning an empty Enumeration. > I have a working implementation and will support the patch for it, this is > the JIRA to track it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NET-594) TelnetClient._closeOutputStream unhandled exception from FilterOutputStream.close
[ https://issues.apache.org/jira/browse/NET-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Worrall updated NET-594: - Description: As part of fixing an existing bug Oracle introduced a new bug into FilterOutputStream.close: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8054565 While the bug is marked as fixed the fix will not be available until Java 9 from what I can tell and is not in the latest release as of writing (1.8.91) This bug can also be reproduced through remote socket closure. Due to this bug the TelnetClient when calling disconnect() throws an unhandled exception and is unable to close the connection, if the socket was remotely closed. Stack Trace: java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:121) at java.net.SocketOutputStream.write(SocketOutputStream.java:147) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at java.io.FilterOutputStream.close(FilterOutputStream.java:159) at org.apache.commons.net.telnet.TelnetClient._closeOutputStream(TelnetClient.java:86) at org.apache.commons.net.telnet.TelnetOutputStream.close(TelnetOutputStream.java:155) at org.apache.commons.net.telnet.TelnetClient.disconnect(TelnetClient.java:127) was: As part of fixing an existing bug Oracle introduced a new bug into FilterOutputStream.close: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8054565 This bug can also be reproduced through remote socket closure. Due to this bug the TelnetClient when calling disconnect() throws an unhandled exception and is unable to close the connection, if the socket was remotely closed. Stack Trace: java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:121) at java.net.SocketOutputStream.write(SocketOutputStream.java:147) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at java.io.FilterOutputStream.close(FilterOutputStream.java:159) at org.apache.commons.net.telnet.TelnetClient._closeOutputStream(TelnetClient.java:86) at org.apache.commons.net.telnet.TelnetOutputStream.close(TelnetOutputStream.java:155) at org.apache.commons.net.telnet.TelnetClient.disconnect(TelnetClient.java:127) > TelnetClient._closeOutputStream unhandled exception from > FilterOutputStream.close > - > > Key: NET-594 > URL: https://issues.apache.org/jira/browse/NET-594 > Project: Commons Net > Issue Type: Bug > Components: Telnet >Affects Versions: 3.4 > Environment: Windows 7 64bit >Reporter: Brad Worrall > > As part of fixing an existing bug Oracle introduced a new bug into > FilterOutputStream.close: > http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8054565 > While the bug is marked as fixed the fix will not be available until Java 9 > from what I can tell and is not in the latest release as of writing (1.8.91) > This bug can also be reproduced through remote socket closure. > Due to this bug the TelnetClient when calling disconnect() throws an > unhandled exception and is unable to close the connection, if the socket was > remotely closed. > Stack Trace: > java.net.SocketException: Socket closed > at > java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:121) > at java.net.SocketOutputStream.write(SocketOutputStream.java:147) > at > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) > at java.io.FilterOutputStream.close(FilterOutputStream.java:159) > at > org.apache.commons.net.telnet.TelnetClient._closeOutputStream(TelnetClient.java:86) > at > org.apache.commons.net.telnet.TelnetOutputStream.close(TelnetOutputStream.java:155) > at > org.apache.commons.net.telnet.TelnetClient.disconnect(TelnetClient.java:127) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NET-594) TelnetClient._closeOutputStream unhandled exception from FilterOutputStream.close
[ https://issues.apache.org/jira/browse/NET-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Worrall updated NET-594: - Description: As part of fixing an existing bug Oracle introduced a new bug into FilterOutputStream.close: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8054565 This bug can also be reproduced through remote socket closure. Due to this bug the TelnetClient when calling disconnect() throws an unhandled exception and is unable to close the connection, if the socket was remotely closed. Stack Trace: java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:121) at java.net.SocketOutputStream.write(SocketOutputStream.java:147) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at java.io.FilterOutputStream.close(FilterOutputStream.java:159) at org.apache.commons.net.telnet.TelnetClient._closeOutputStream(TelnetClient.java:86) at org.apache.commons.net.telnet.TelnetOutputStream.close(TelnetOutputStream.java:155) at org.apache.commons.net.telnet.TelnetClient.disconnect(TelnetClient.java:127) was: As part of fixing an existing bug Oracle introduced a new bug into FilterOutputStream.close: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8054565 This bug can also be reproduced through remote socket closure. Due to this bug the TelnetClient when calling disconnect() throws an unhandled exception and is unable to close the socket, if the socket was remotely closed. Stack Trace: java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:121) at java.net.SocketOutputStream.write(SocketOutputStream.java:147) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at java.io.FilterOutputStream.close(FilterOutputStream.java:159) at org.apache.commons.net.telnet.TelnetClient._closeOutputStream(TelnetClient.java:86) at org.apache.commons.net.telnet.TelnetOutputStream.close(TelnetOutputStream.java:155) at org.apache.commons.net.telnet.TelnetClient.disconnect(TelnetClient.java:127) > TelnetClient._closeOutputStream unhandled exception from > FilterOutputStream.close > - > > Key: NET-594 > URL: https://issues.apache.org/jira/browse/NET-594 > Project: Commons Net > Issue Type: Bug > Components: Telnet >Affects Versions: 3.4 > Environment: Windows 7 64bit >Reporter: Brad Worrall > > As part of fixing an existing bug Oracle introduced a new bug into > FilterOutputStream.close: > http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8054565 > This bug can also be reproduced through remote socket closure. > Due to this bug the TelnetClient when calling disconnect() throws an > unhandled exception and is unable to close the connection, if the socket was > remotely closed. > Stack Trace: > java.net.SocketException: Socket closed > at > java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:121) > at java.net.SocketOutputStream.write(SocketOutputStream.java:147) > at > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) > at java.io.FilterOutputStream.close(FilterOutputStream.java:159) > at > org.apache.commons.net.telnet.TelnetClient._closeOutputStream(TelnetClient.java:86) > at > org.apache.commons.net.telnet.TelnetOutputStream.close(TelnetOutputStream.java:155) > at > org.apache.commons.net.telnet.TelnetClient.disconnect(TelnetClient.java:127) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NET-594) TelnetClient._closeOutputStream unhandled exception from FilterOutputStream.close
Brad Worrall created NET-594: Summary: TelnetClient._closeOutputStream unhandled exception from FilterOutputStream.close Key: NET-594 URL: https://issues.apache.org/jira/browse/NET-594 Project: Commons Net Issue Type: Bug Components: Telnet Affects Versions: 3.4 Environment: Windows 7 64bit Reporter: Brad Worrall As part of fixing an existing bug Oracle introduced a new bug into FilterOutputStream.close: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8054565 This bug can also be reproduced through remote socket closure. Due to this bug the TelnetClient when calling disconnect() throws an unhandled exception and is unable to close the socket, if the socket was remotely closed. Stack Trace: java.net.SocketException: Socket closed at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:121) at java.net.SocketOutputStream.write(SocketOutputStream.java:147) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) at java.io.FilterOutputStream.close(FilterOutputStream.java:159) at org.apache.commons.net.telnet.TelnetClient._closeOutputStream(TelnetClient.java:86) at org.apache.commons.net.telnet.TelnetOutputStream.close(TelnetOutputStream.java:155) at org.apache.commons.net.telnet.TelnetClient.disconnect(TelnetClient.java:127) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (BCEL-273) Regressions running FindBugs on BCEL6
[
https://issues.apache.org/jira/browse/BCEL-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Loskutov updated BCEL-273:
-
Attachment: BetterCFGBuilder2.java
[~dbrosius]: thanks for the pointers!
I've pushed https://github.com/findbugsproject/findbugs/commits/java9_bcel6_old
branch which applies the DismantleBytecode fix proposed earlier - this works!
The current (last visible) problem is ClassCastException in
org.apache.commons.bcel6.generic.BranchHandle.getBI(BranchHandle.java:64).
If I change BranchHandle.java to
https://github.com/iloveeclipse/commons-bcel/commit/25dfa20fd99e4053e68b6054ff21f55fd915e003,
the CCE disappear and all FB tests pass on Java 8.
However I've failed to do a fix on the FB side which would NOT require
https://github.com/iloveeclipse/commons-bcel/commit/25dfa20fd99e4053e68b6054ff21f55fd915e003.
If I change FB code, see attached BetterCFGBuilder2.java, I see other errors,
and tests are still failing.
I've never used BCEL before, so my primitive fix was to replace calls to
{code}
InstructionHandle head;
Instruction replacement;
...
head.swapInstruction(replacement);
{code}
with
{code}
...
head = swapInstruction(instructionList, head, replacement);
...
static InstructionHandle swapInstruction(InstructionList list,
InstructionHandle handle, Instruction i){
InstructionHandle newOne = list.insert(handle, i);
try {
list.delete(handle);
} catch (TargetLostException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return newOne;
}
{code}
I'm not sure if replacing BranchInstruction by ConversionInstruction in the way
as it shown above is a good idea (I see that the TargetLostException are flying
around which means we have some loose ends in the list). But honestly speaking,
I have no clue how the BetterCFGBuilder2 code works and how to fix it in the
"right" way.
In that sense, [~s...@apache.org]: WDYT about
https://github.com/iloveeclipse/commons-bcel/commit/25dfa20fd99e4053e68b6054ff21f55fd915e003?
> Regressions running FindBugs on BCEL6
> -
>
> Key: BCEL-273
> URL: https://issues.apache.org/jira/browse/BCEL-273
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 6.0
>Reporter: Andrey Loskutov
>Priority: Blocker
> Fix For: 6.0
>
> Attachments: BetterCFGBuilder2.java, bcel6_test_result.txt,
> invokedynamic.txt
>
>
> h5. PREFACE
> I'm trying to port FindBugs to the latest greatest BCEL 6 state from trunk,
> see https://github.com/findbugsproject/findbugs/issues/106.
> In short, FindBugs was using some manually created BCEL 5.2 fork which
> allowed us somehow run BCEL on Java 8 and even Java 9.
> Unfortunately I have no idea how to rebuild that fork, because no one in the
> project left any documentation.
> So anyway, my goal was to use unmodified BCEL6, therefore I fixed all compile
> issues caused by BCEL-222 ((n)) and was able to run FB with BCEL6 head.
>
> Unfortunately I found some regressions.
> h5. Environment
> I'm using my own git clone from BCEL mirror
> https://github.com/iloveeclipse/commons-bcel/commits/trunk
> The clone only adds few Eclipse files and fixes some obvious errors, nothing
> worth to mention here. The reason why I'm not using svn because it is too
> slow and I won't waste my time.
> To see commits I needed to port FB to BCEL6 port, go to
> https://github.com/findbugsproject/findbugs/tree/java9_bcel6
> h5. How to reproduce
> {code}
> git clone https://github.com/findbugsproject/findbugs.git
> cd findbugs
> git checkout java9_bcel6
> cd findbugs
> ant
> cd ../findbugsTestCases
> ant
> {code}
> You should run Java 8.
> After running tests, you should see many various errors, like:
> https://github.com/findbugsproject/findbugs/files/300401/bcel6_test_result.txt
> None of those error appear with the old private patched BCEL5.2 snapshot
> we've used before.
> It would be nice to fix the errors before the BCEL release.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COLLECTIONS-590) MapUtils.EMPTY_SORTED_MAP should be renamed - UnmodifiableSortedMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible updated COLLECTIONS-590: --- Issue Type: Improvement (was: Bug) > MapUtils.EMPTY_SORTED_MAP should be renamed - UnmodifiableSortedMap > --- > > Key: COLLECTIONS-590 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-590 > Project: Commons Collections > Issue Type: Improvement >Reporter: Philipp Schneider > > When using the constant MapUtils.EMPTY_SORTED_MAP I assume from the name, > that it will return an empty sorted map. > But the map is an UnmodifiableSortedMap. > The Javadoc says this, but still the naming is not really good. > I suggest the following new name: EMPTY_UNMODIFIABLE_SORTED_MAP -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COLLECTIONS-590) MapUtils.EMPTY_SORTED_MAP should be renamed - UnmodifiableSortedMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible resolved COLLECTIONS-590. Resolution: Won't Fix The names follow the same logic as their counter parts in the JDK. An empty sorted map is always empty and therefore implicitly unmodifiable. > MapUtils.EMPTY_SORTED_MAP should be renamed - UnmodifiableSortedMap > --- > > Key: COLLECTIONS-590 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-590 > Project: Commons Collections > Issue Type: Improvement >Reporter: Philipp Schneider >Priority: Minor > > When using the constant MapUtils.EMPTY_SORTED_MAP I assume from the name, > that it will return an empty sorted map. > But the map is an UnmodifiableSortedMap. > The Javadoc says this, but still the naming is not really good. > I suggest the following new name: EMPTY_UNMODIFIABLE_SORTED_MAP -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COLLECTIONS-590) MapUtils.EMPTY_SORTED_MAP should be renamed - UnmodifiableSortedMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible updated COLLECTIONS-590: --- Priority: Minor (was: Major) > MapUtils.EMPTY_SORTED_MAP should be renamed - UnmodifiableSortedMap > --- > > Key: COLLECTIONS-590 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-590 > Project: Commons Collections > Issue Type: Improvement >Reporter: Philipp Schneider >Priority: Minor > > When using the constant MapUtils.EMPTY_SORTED_MAP I assume from the name, > that it will return an empty sorted map. > But the map is an UnmodifiableSortedMap. > The Javadoc says this, but still the naming is not really good. > I suggest the following new name: EMPTY_UNMODIFIABLE_SORTED_MAP -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COLLECTIONS-590) MapUtils.EMPTY_SORTED_MAP should be renamed - UnmodifiableSortedMap
Philipp Schneider created COLLECTIONS-590: - Summary: MapUtils.EMPTY_SORTED_MAP should be renamed - UnmodifiableSortedMap Key: COLLECTIONS-590 URL: https://issues.apache.org/jira/browse/COLLECTIONS-590 Project: Commons Collections Issue Type: Bug Reporter: Philipp Schneider When using the constant MapUtils.EMPTY_SORTED_MAP I assume from the name, that it will return an empty sorted map. But the map is an UnmodifiableSortedMap. The Javadoc says this, but still the naming is not really good. I suggest the following new name: EMPTY_UNMODIFIABLE_SORTED_MAP -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (BCEL-92) Properly parse StackMapTable attributes in Java 6 classfiles
[ https://issues.apache.org/jira/browse/BCEL-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15320370#comment-15320370 ] ASF GitHub Bot commented on BCEL-92: Github user asfgit closed the pull request at: https://github.com/apache/commons-bcel/pull/5 > Properly parse StackMapTable attributes in Java 6 classfiles > > > Key: BCEL-92 > URL: https://issues.apache.org/jira/browse/BCEL-92 > Project: Commons BCEL > Issue Type: Improvement > Components: Main >Affects Versions: unspecified >Reporter: Michael Martin >Assignee: Apache Commons Developers >Priority: Blocker > Fix For: 6.0 > > Attachments: StackMapTable.patch, java6stackmap.patch > > > Java 6 includes a "StackMapTable" type that is used for its new split > verification scheme. This means many Code attributes will have StackMapTable > attributes attached. This format is similar but not quite identical to the > already implemented StackMap. > I have developed a patch that adds the necessary functionality to the > classfile > parser (mostly by copy-pasting code from StackMap and StackMapEntry), and will > attach it shortly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (BCEL-92) Properly parse StackMapTable attributes in Java 6 classfiles
[ https://issues.apache.org/jira/browse/BCEL-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15320370#comment-15320370 ] ASF GitHub Bot commented on BCEL-92: Github user asfgit closed the pull request at: https://github.com/apache/commons-bcel/pull/5 > Properly parse StackMapTable attributes in Java 6 classfiles > > > Key: BCEL-92 > URL: https://issues.apache.org/jira/browse/BCEL-92 > Project: Commons BCEL > Issue Type: Improvement > Components: Main >Affects Versions: unspecified >Reporter: Michael Martin >Assignee: Apache Commons Developers >Priority: Blocker > Fix For: 6.0 > > Attachments: StackMapTable.patch, java6stackmap.patch > > > Java 6 includes a "StackMapTable" type that is used for its new split > verification scheme. This means many Code attributes will have StackMapTable > attributes attached. This format is similar but not quite identical to the > already implemented StackMap. > I have developed a patch that adds the necessary functionality to the > classfile > parser (mostly by copy-pasting code from StackMap and StackMapEntry), and will > attach it shortly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (BCEL-92) Properly parse StackMapTable attributes in Java 6 classfiles
[ https://issues.apache.org/jira/browse/BCEL-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15320289#comment-15320289 ] ASF GitHub Bot commented on BCEL-92: GitHub user iloveeclipse opened a pull request: https://github.com/apache/commons-bcel/pull/5 BCEL6 compatibility to 5.2 snapshots First commit: added Git ignore file Second commit: follow up on the BCEL6 compatibility discussion. Attempt to fix the StackMapTable misery, see BCEL-92 and BCEL-248 Added StackMapTable/StackMapTableEntry back, basically 1:1 copy of StackMap/StackMapEntry. Added related, previously removed constants back to Constants (not they match those from Const). Updated Visitor* interfaces to handle both types. Updated Attaribute to create StackMapTable in case we see "StackMapTable" attribute. You can merge this pull request into a Git repository by running: $ git pull https://github.com/iloveeclipse/commons-bcel apache/trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-bcel/pull/5.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5 commit 5e94bac1078d98a7f36fd3e6642a71c7d0642e64 Author: Andrey Loskutov Date: 2016-06-08T06:27:45Z Added Git ignore file commit ff83f03d3314fa169917a7f523937373f3dda966 Author: Andrey Loskutov Date: 2016-06-08T09:25:29Z Attempt to fix the StackMapTable misery, see BCEL-92 and BCEL-248 Added StackMapTable/StackMapTableEntry back, basically 1:1 copy of StackMap/StackMapEntry. Added related, previously removed constants back to Constants (not they match those from Const). Updated Visitor* interfaces to handle both types. Updated Attaribute to create StackMapTable in case we see "StackMapTable" attribute. > Properly parse StackMapTable attributes in Java 6 classfiles > > > Key: BCEL-92 > URL: https://issues.apache.org/jira/browse/BCEL-92 > Project: Commons BCEL > Issue Type: Improvement > Components: Main >Affects Versions: unspecified >Reporter: Michael Martin >Assignee: Apache Commons Developers >Priority: Blocker > Fix For: 6.0 > > Attachments: StackMapTable.patch, java6stackmap.patch > > > Java 6 includes a "StackMapTable" type that is used for its new split > verification scheme. This means many Code attributes will have StackMapTable > attributes attached. This format is similar but not quite identical to the > already implemented StackMap. > I have developed a patch that adds the necessary functionality to the > classfile > parser (mostly by copy-pasting code from StackMap and StackMapEntry), and will > attach it shortly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (BCEL-92) Properly parse StackMapTable attributes in Java 6 classfiles
[ https://issues.apache.org/jira/browse/BCEL-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15320289#comment-15320289 ] ASF GitHub Bot commented on BCEL-92: GitHub user iloveeclipse opened a pull request: https://github.com/apache/commons-bcel/pull/5 BCEL6 compatibility to 5.2 snapshots First commit: added Git ignore file Second commit: follow up on the BCEL6 compatibility discussion. Attempt to fix the StackMapTable misery, see BCEL-92 and BCEL-248 Added StackMapTable/StackMapTableEntry back, basically 1:1 copy of StackMap/StackMapEntry. Added related, previously removed constants back to Constants (not they match those from Const). Updated Visitor* interfaces to handle both types. Updated Attaribute to create StackMapTable in case we see "StackMapTable" attribute. You can merge this pull request into a Git repository by running: $ git pull https://github.com/iloveeclipse/commons-bcel apache/trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-bcel/pull/5.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5 commit 5e94bac1078d98a7f36fd3e6642a71c7d0642e64 Author: Andrey Loskutov Date: 2016-06-08T06:27:45Z Added Git ignore file commit ff83f03d3314fa169917a7f523937373f3dda966 Author: Andrey Loskutov Date: 2016-06-08T09:25:29Z Attempt to fix the StackMapTable misery, see BCEL-92 and BCEL-248 Added StackMapTable/StackMapTableEntry back, basically 1:1 copy of StackMap/StackMapEntry. Added related, previously removed constants back to Constants (not they match those from Const). Updated Visitor* interfaces to handle both types. Updated Attaribute to create StackMapTable in case we see "StackMapTable" attribute. > Properly parse StackMapTable attributes in Java 6 classfiles > > > Key: BCEL-92 > URL: https://issues.apache.org/jira/browse/BCEL-92 > Project: Commons BCEL > Issue Type: Improvement > Components: Main >Affects Versions: unspecified >Reporter: Michael Martin >Assignee: Apache Commons Developers >Priority: Blocker > Fix For: 6.0 > > Attachments: StackMapTable.patch, java6stackmap.patch > > > Java 6 includes a "StackMapTable" type that is used for its new split > verification scheme. This means many Code attributes will have StackMapTable > attributes attached. This format is similar but not quite identical to the > already implemented StackMap. > I have developed a patch that adds the necessary functionality to the > classfile > parser (mostly by copy-pasting code from StackMap and StackMapEntry), and will > attach it shortly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NET-593) HostnameVerifier is checking for ip addess
Jörg Weule created NET-593: -- Summary: HostnameVerifier is checking for ip addess Key: NET-593 URL: https://issues.apache.org/jira/browse/NET-593 Project: Commons Net Issue Type: Bug Components: SMTP Affects Versions: 3.4 Reporter: Jörg Weule When TLS is used (not StartTLS) on port 465, the HostnameVerifier is checking for the ip address, not the hostname. This results in a failure on each connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
