Sat 12 Mar 2016 07:03:20 PM UTC, comment #9:
@Avinoam: I've noticed bug report #47372 about memory leaks, that seems to go along this direction. So I decided to not open an additional bug report for now.
|
Thu 10 Mar 2016 05:09:34 PM UTC, comment #8:
@Hartmut:
I think it's a good idea to open
a seperate bug report on this problem.
|
Thu 10 Mar 2016 09:07:32 AM UTC, comment #7:
@ Avinoam:
I have had a look at bug report #43505, and this looks very odd, indeed. Seems that some Octave function calls are messed up, once Java stuff has been used before. Rik thought this might be due to memory leaks in Octave.
Should we open a new bug report dedicated to this issue? The facts so far are (at least):
- bug #43505 : After using java, the image saved by imwrite has all elements lower by one value.
- this bug (#47386): svds.m gives different results when java has been used before (but I haven't tried to reproduce this yet).
If this points to memory leaks, it should be worth fixing. (My deepest hope would even be to eventually find the root cause of image-i/o crashing Octave on Windows during shutdown, bug #41699, still present in 4.0.1-rc3)
|
Thu 10 Mar 2016 05:50:20 AM UTC, comment #6:
@Hartmut:
> Do you have an explanation why "test svds.m" passes all tests, whereas run_test_suite gives a failing test on svds.m?)
I do not have an answer, but please see the my original
bug report on bug #46683. It was somehow swept under the carpet,
but this is related in someway to "jobj = javaObject ("java.lang.StringBuffer");" appears in the run_test_suite.
bug #43505 has similar problem.
|
Wed 09 Mar 2016 08:47:02 PM UTC, comment #5:
There was an outstanding question by me (Rik) on bug #46683 about whether this should be backported to stable. I never got a response, but it seems like it should be. I did that here (http://hg.savannah.gnu.org/hgweb/octave/rev/e169fe73b57e). This should fix things up when the 4.0.1-rc4 candidate comes out. Or you can grab the stable branch from Mercurial and use MXE to cross-compile.
|
Wed 09 Mar 2016 08:34:56 PM UTC, comment #4:
I have no competence in deciding which patches to backport do stable. But I think an official release (in this case 4.0.1) should normally not have any failing unit tests.
(Do you have an explanation why "test svds.m" passes all tests, whereas _run_test_suite_ gives a failing test on svds.m?)
|
Wed 09 Mar 2016 08:29:02 PM UTC, comment #3:
That makes sense, because that fix was applied to the default branch, not stable, so it will be available in the Octave 4.2 release. Is this worth backporting to stable?
This was part of bug #46683.
|
Wed 09 Mar 2016 08:22:11 PM UTC, comment #2:
In the file svds.m I find the following code:
I think this means that the patch you mentioned is NOT included here.
The windows version of 4.0.1-rc3 that gave me this error was installed from the "official" exe-installer at alpha.gnu.org/gnu/octave .
Looking at the mentioned patch, it seems to me that is was only applied to the default branch in the repository. I assume that the 4.0.1 release will be taken from the stable branch. Maybe this is why this patch is not included in the 4.0.1-rc3 release candidate?
Note: When I only run "test svds.m" in this installation then I get 6 passing tests (out of 6), no errors in this case. Even running this test 100 times (in a for loop) only gives me passing tests. I don't understand this. If you want me to rerun the _run_test_suite_ command again on this installation, then please let me know (it takes quite a while on this computer...)
|
Wed 09 Mar 2016 05:45:58 PM UTC, comment #1:
Can you take a look at the file
and make sure it contains the changes in this cset: http://hg.savannah.gnu.org/hgweb/octave/rev/73f62b4bb533.
If those lines are missing, then that is why the test is failing. If those lines are present, then we have a problem.
|
Wed 09 Mar 2016 08:47:25 AM UTC, original submission:
When I run the test suite of Octave 4.0.1-rc3 under Windows 7 I get the following result:
The one failing test is in svds.m:
This is probably related to bug #46683 and others. I nevertheless opened a new report, because I assumed that a release candidate should have zero failing tests, normally.
|