bugGNU Octave - Bugs: bug #40381, MXE / MinGW - setenv does not work...

 
 

bug #40381: MXE / MinGW - setenv does not work correctly

Submitter:  John Donoghue <lostbard>
Submitted:  Sat 26 Oct 2013 05:49:31 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  John D Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 13 Nov 2013 04:57:14 PM UTC, comment #41: 

The original bug, setenv on MinGW, seems to have been fixed, so I'm going to close this report.  Any other issues, such as failing tests, can be put under a new bug report.

Rik <rik5>
Group administrator
Mon 11 Nov 2013 06:15:54 PM UTC, comment #40: 

Running debug using the cross build mxe:

>> test ndgrid
stopped in
C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\plot\util\ndgrid.m at line
43
43:   if (nargin == 0)
debug> whos varargin
Variables in the current scope:

   Attr Name          Size                     Bytes  Class
   ==== ====          ====                     =====  =====
    f   varargin      1x1                         24  cell

Total is 1 element using 24 bytes
debug>
stopped in
C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\plot\util\ndgrid.m at line
45
45:   elseif (nargin == 1)
debug>
stopped in
C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\plot\util\ndgrid.m at line
46
46:     n = max ([nargout, 1]);
debug>
stopped in
C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\plot\util\ndgrid.m at line
48
48:     varargin(1:n) = varargin(1);
debug>
stopped in
C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\plot\util\ndgrid.m at line
57
57:   shape = zeros (1, n);
debug> n
n =  1
debug>
stopped in
C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\plot\util\ndgrid.m at line
58
58:   for i = 1:n
debug>
stopped in
C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\plot\util\ndgrid.m at line
59
59:     if (! isvector (varargin{i}) && ! isempty (varargin{i}))
debug>
stopped in
C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\plot\util\ndgrid.m at line
62
62:     shape(i) = length (varargin{i});
debug> whos varargin{i}
Variables in the current scope:

   Attr Name             Size                     Bytes  Class
   ==== ====             ====                     =====  =====
    f   varargin{i}      1x3                         24  double

Total is 3 elements using 24 bytes
debug>
stopped in
C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\plot\util\ndgrid.m at line
65
65:   for i = 1:n
debug>
stopped in
C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\plot\util\ndgrid.m at line
67
67:     r = ones (1, n);
debug>
stopped in
C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\plot\util\ndgrid.m at line
68
68:     r(i) = shape(i);
debug>
stopped in
C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\plot\util\ndgrid.m at line
71
71:     s = shape;
debug>
stopped in
C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\plot\util\ndgrid.m at line
72
72:     s(i) = 1;
debug>
stopped in
C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\plot\util\ndgrid.m at line
74
74:     varargout{i} = repmat (reshape (varargin{i}, r), s);
debug> whos r
Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        r           1x1                          8  double

Total is 1 element using 8 bytes

debug> whos s
Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        s           1x1                          8  double

Total is 1 element using 8 bytes
debug> varargin{i}
ans =

   1   2   3
debug> r
r =  3
debug> s
s =  1
debug> dbnext
error: reshape: can't reshape 1x3 array to 3x0 array
error: evaluating argument list element number 1
error: called from:
error:   C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\plot\util\ndgrid.m
at line 74, column 17
error: evaluating argument list element number 1
error: evaluating argument list element number 1
error:   __test__ at line 4, column 2
stopped in C:\octave-2013-11-09-19-03\share\octave\3.7.7+\m\testfun\test.m
at line 529
529:         if (strcmp (__type, "xtest"))
debug>


John Donoghue <lostbard>
Group Member
Mon 11 Nov 2013 02:35:46 AM UTC, comment #39: 

Looking over the failed tests, one caught my eye.


x = 1:3;
assert (isequal (ndgrid (x), x(:)));
ASSERT errors for:  assert (ndgrid ([]),zeros (0, 1))
reshape: can't reshape 1x3 array to 3x0 array


I think it would be worth setting a breakpoint in ndgrid and then single-stepping through the code to see where the problem lies.  ndgrid.m is a short file so it should be easy.

Rik <rik5>
Group administrator
Sun 10 Nov 2013 08:34:53 PM UTC, comment #38: 

For running the installed (native compiled octave), I end up with:
                                                                                                         
Summary:

  PASS     11293
  FAIL        12

See the file test/fntests.log for additional details.

245 (of 831) .m files have no tests.


John Donoghue <lostbard>
Group Member
Sun 10 Nov 2013 01:34:03 PM UTC, comment #37: 

I compiled last night using the latest make dist devel tarball of 3.7.7+ in mxe-octave cross build and native build and installed.

Both ran ok in regards to the program running from octave.exe.

Running the tests gave a number of failures, each stopped and core dumped when they were doing the jit tests.

I have attached a partial diff of the test results file from both the cross/native installed version.

(file #29584)

John Donoghue <lostbard>
Group Member
Sun 10 Nov 2013 04:41:41 AM UTC, comment #36: 

Let's assume for the moment that it is a problem with libtool and run-octave.  What happens if you do actually install octave, 'make install', and then try running the installed octave executable?  If it loads correctly, does '__run_test_suite__ ()' pass most tests?

Rik <rik5>
Group administrator
Sat 09 Nov 2013 01:39:20 PM UTC, comment #35: 

Something with the libtool execute?

If I change the name to something wrong, exec returns back an error, so it is getting running something ok.

If I add a print statement in main-gui.cc, it is not displayed.

John Donoghue <lostbard>
Group Member
Fri 08 Nov 2013 02:25:43 PM UTC, comment #34: 


$ ./run-octave
exec filename C:/MinGW/msys/1.0/home/jdonoghue/mxe-octave/octave_hg/build/src\oc
tave-gui


John Donoghue <lostbard>
Group Member
Fri 08 Nov 2013 01:57:38 AM UTC, comment #33: 

Can you add this statement to line 372 of main.in.cc.


  std::cerr << "exec filename " << file.c_str () << std::endl;


When you then do run-octave it should print out what filename it is trying to execute.

Rik <rik5>
Group administrator
Fri 08 Nov 2013 12:45:46 AM UTC, comment #32: 

It was still yesterday

John Donoghue <lostbard>
Group Member
Fri 08 Nov 2013 12:05:01 AM UTC, comment #31: 

Is the problem with run-octave not working still present on MinGW?  The code base has been changing every day pretty significantly for the last 5 days.

If it is still present, I think we might need to put in some printf() statements to see what is going on.

Rik <rik5>
Group administrator
Sun 03 Nov 2013 01:27:32 AM UTC, comment #30: 


$ ls src
Makefile      mkoctfile.exe     octave-config.exe  octave.exe
main-cli.o    mkoctfile.o       octave-config.o    octave_gui-main-gui.o
main.cc       octave-cli.exe    octave-gui.exe
mkoctfile.cc  octave-config.cc  octave-main.o

$ ls src/.libs/
lt-mkoctfile.c      mkoctfile.exe           octave-config_ltshwrapper
lt-octave-cli.c     mkoctfile_ltshwrapper   octave-gui.exe
lt-octave-config.c  octave-cli.exe          octave-gui_ltshwrapper
lt-octave-gui.c     octave-cli_ltshwrapper  octave.exe
lt-octave.c         octave-config.exe       octave_ltshwrapper


John Donoghue <lostbard>
Group Member
Sat 02 Nov 2013 10:36:18 PM UTC, comment #29: 

Offhand, the script is complaining about missing the octave executable.  Do you have a file src/octave which is executable?  Or is it only src/octave-cli and src/octave-gui?  If it is there, does it have the correct extension?

Rik <rik5>
Group administrator
Fri 01 Nov 2013 04:35:31 PM UTC, comment #28: 

I was running the windows (native compiled) version.

I have pulled since but still show the same issue.


$ hg id
ebb3ef964372 tip @

$ ./run-octave --eval "exp (1)"
$ octave:./.libs/lt-octave-gui.c:233: FATAL: couldn't find octave.

$ ./run-octave -f --eval "exp (1)"
octave:./.libs/lt-octave-gui.c:233: FATAL: couldn't find octave.

$ ./run-octave --no-gui-libs --eval "exp (1)"
octave:./.libs/lt-octave-cli.c:233: FATAL: couldn't find octave.



run-octave.in (and run-octave) have the following in their arg parsing:

  elif [ "x$1" = "x-cli" ]; then
    octave_executable="$builddir/src/octave-cli"
    shift
  fi


Running './run-octave -cli' still works.

Running others without the run-octave script:

$ ./src/octave
octave: failed to exec '\home\jdonoghue\mxe-octave\bin\octave-gui'
$ ./src/octave-gui.exe  (works)



John Donoghue <lostbard>
Group Member
Fri 01 Nov 2013 01:58:47 PM UTC, comment #27: 

What hg id were you using for your tests on minGW?

Also, you mentioned the '-cli' option.  Did you mean '--no-gui-libs'?  There isn't any such option on the Linux version.

Finally, could you try these three tests?


./run-octave --eval "exp (1)"
./run-octave -f --eval "exp (1)"
./run-octave --no-gui-libs --eval "exp (1)"


Rik <rik5>
Group administrator
Fri 01 Nov 2013 01:25:40 AM UTC, comment #26: 

if I run: ./run_octave -clii, the command line version runs fine.
If I change the octave_executable variable in run_octave to octave-gui, the gui runs ok.

John Donoghue <lostbard>
Group Member
Fri 01 Nov 2013 12:53:17 AM UTC, comment #25: 

On compiling the docs in native ming:

Making all in interpreter
make[3]: Entering directory `/home/jdonoghue/mxe-octave/octave_hg/build/doc/inte
rpreter'
../../run-octave -f -q -H -p ../../../doc/interpreter --eval "geometryimages ('v
oronoi', 'eps');"
../../run-octave -f -q -H -p ../../../doc/interpreter --eval "geometryimages ('t
riplot', 'eps');"
octave:./.libs/lt-octave-gui.c:233: FATAL: couldn't find octave.


Running run-octave from the build directory fails:

$ octave:./.libs/lt-octave-gui.c:233: FATAL: couldn't find octave.


John Donoghue <lostbard>
Group Member
Wed 30 Oct 2013 10:48:56 AM UTC, comment #24: 

My native ming version is doing a couple of weird things still, but I believe they were self inflicted when I was playing around with trying to get it to run, so I am rebuilding mxe and octave to check it is working.

John Donoghue <lostbard>
Group Member
Tue 29 Oct 2013 08:28:10 PM UTC, comment #23: 

@ John (JWE): your fix works OK for me; the /bin subdir is added to the PATH now when executing octave.exe directly, and octave-gui.exe is started. On my WinXP box:

>> strsplit (getenv ("PATH"), pathsep)
ans =
{
  [1,1] = C:\WINDOWS\system32
  [1,2] = C:\WINDOWS
  [1,3] = C:\WINDOWS\System32\Wbem
  [1,4] = C:\Programs\TortoiseSVN\bin
  [1,5] = C:\Programs\gs\gs9.04\bin
  [1,6] = C:\Programs\QuickTime\QTSystem\
  [1,7] = C:\Programs\Mercurial
  [1,8] = X:\Octave\octave-2013-10-29-19-15\bin
  [1,9] = X:\Octave\octave-2013-10-29-19-15\notepad++
  [1,10] = X:\Octave\octave-2013-10-29-19-15\libexec\octave\3.7.7+\site\exec\i686-pc-mingw32
  [1,11] = X:\Octave\octave-2013-10-29-19-15\libexec\octave\api-v48+\site\exec\i686-pc-mingw32
  [1,12] = X:\Octave\octave-2013-10-29-19-15\libexec\octave\site\exec\i686-pc-mingw32
  [1,13] = X:\Octave\octave-2013-10-29-19-15\libexec\octave\3.7.7+\exec\i686-pc-mingw32
  [1,14] = X:\Octave\octave-2013-10-29-19-15\bin
}
>>


/bin has been added twice, but that isn't in the way.

Is it really necessary to add the libexec/.../i686-pc-mingw32 subdirs to the PATH? (not that it is harmful in any way) - I see no difference with the current situation and the previous one where I only had /bin added (by calling Octave from a batch file that first added (only) /bin to the PATH).

Do we leave it to John Donoghue to close this bug?

Philip Nienhuis <philipnienhuis>
Group Member
Tue 29 Oct 2013 11:13:15 AM UTC, comment #22: 

I don't (= can't in MXE presently) build with LLVM either, and Java only has 2 tests ATM (in ov_java.cc).
Didn't you see the 20 classdef test FAILs? Perhaps they are properly skipped in your case.

As to the PATH setting, does Octave now add OCTAVE_HOME/bin to the (Windows) PATH in its process? Couldn 't track that down in your latest series of patches (I'm no C++ expert).

I'll try to rebuild & test tonight.


Philip Nienhuis <philipnienhuis>
Group Member
Tue 29 Oct 2013 05:37:54 AM UTC, comment #21: 

I checked in the following change to fix the setenv/putenv problem.  It seems to work for me.

  http://hg.savannah.gnu.org/hgweb/octave/rev/415583856971

I guess this is the reward I get for trying to fix a memory leak.  :-(

It would probably be better to figure out why gnulib::setenv isn't working, but for now I'm going with this change.

This does improve the situation for me with the tests.  Now I'm seeing 11402 PASS, 22 FAIL, 4 XFAIL, and 55 SKIPPED.  I'm not building with LLVM or JAVA, so that's probably why the skipped count is so high.

Now that Octave can properly set the PATH before executing programs, I'm not seeing the messages about makeinfo.  I am still seeing a series of permission denied errors from system-tst about date.m.  It looks like it is searching the load path for date.m and giving a permission denied error about the file in each directory of the load path.  I don't know what that's about, but anyway things look a lot better to me now than they did this time yesterday...

John W. Eaton <jwe>
Group administrator
Tue 29 Oct 2013 01:39:20 AM UTC, comment #20: 

There was a minor typo in 7ae9bc04ec07, fixed in 34d9812a943b, so the octave command should run the GUI again now. Can't comment on the rest.

Mike Miller <mtmiller>
Group Member
Mon 28 Oct 2013 11:08:58 PM UTC, comment #19: 

Thanks.

I just tried the tip 17784:7ae9bc04ec07  (MXE cross build on WinXP)

1. When closing octave (CLI and GUI), I now see an error message flashing by:

>> error: permission denied
error: ignoring octave_execute_exception while preparing exit


(Text could be a little different as it shows maybe 0.25 sec before the Octave windows disappears).

2. When starting octave.exe, I get the CLI; with or without the --force-gui flag makes no difference.
I need to explicitly start octave-gui.exe to start the GUI.
From the post you referred to I can't figure out whether that is the intended behavior (but OK it is bed time here).

Starting octave-gui with --no-gui flag makes octave-cli start.

Please interpret the following just as a report. If it is like you expect, good, please ignore.

Starting Octave from a cmd32 command prompt ("Windows shell") gives funny results:

X:\Octave\octave-2013-10-28-22-49\bin>octave
    <6 seconds wait ....>
X:\Octave\octave-2013-10-28-22-49\bin>GNU Octave, version 3.7.7+
Copyright (C) 2013 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "i686-pc-mingw32".

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/get-involved.html

Read http://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

octave:1> a = 10
'a' is not recognized as an internal or external command,
operable program or batch file.

X:\Octave\octave-2013-10-28-22-49\bin>     <just hit Enter key..>
octave:1> whos
'whos' is not recognized as an internal or external command,
operable program or batch file.

X:\Octave\octave-2013-10-28-22-49\bin>     <just hit Enter key..>
octave:1>                                  <just hit Enter key..>
X:\Octave\octave-2013-10-28-22-49\bin>
octave:1>                                          <ditto>
X:\Octave\octave-2013-10-28-22-49\bin>
octave:1>
X:\Octave\octave-2013-10-28-22-49\bin>
octave:1>
X:\Octave\octave-2013-10-28-22-49\bin>


... so once octave is started, hitting the Enter key switches between the cmd32 terminal and the Octave prompt. Although / while an octave prompt is displayed, it doesn't seem that octave accepts octave commands.

Now, running octave-cli from a command prompt behaves as expected:

X:\Octave\octave-2013-10-28-22-49\bin>octave-cli
GNU Octave, version 3.7.7+
Copyright (C) 2013 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "i686-pc-mingw32".

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/get-involved.html

Read http://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

octave-cli:1> a = 10
a =  10
octave-cli:2> exit

error: Permission denied
error: ignoring octave_execution_exception while preparing to exit

X:\Octave\octave-2013-10-28-22-49\bin>     <hit Enter key>
X:\Octave\octave-2013-10-28-22-49\bin>


Same goes for octave-gui.exe, only the error message is shown in the terminal pane.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 28 Oct 2013 09:07:52 PM UTC, comment #18: 

There was also some discussion about this on the maintainers list.  My last post is here:

https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2013-October/037057.html

The thread is "gui/pager problem on MacOSX".

John W. Eaton <jwe>
Group administrator
Mon 28 Oct 2013 08:59:44 PM UTC, comment #17: 

Never mind last question, found reason in the log (changeset 17778:b5d58667d32d). Sorry

Philip Nienhuis <philipnienhuis>
Group Member
Mon 28 Oct 2013 08:37:05 PM UTC, comment #16: 

OK, found fntests.log in OCTAVE_HOME/bin (remarkable that Windows search didn't find it - I must have misspelled the name).

Apart from the new FAILs this binary runs fairly well.

What was the reason to have another Octave binary? I didn't catch that on the maintainers ML or in the bug tracker.
(At first sight it looks just more complicating, but (as always) you'll probably have good reasons for it.)

Philip Nienhuis <philipnienhuis>
Group Member
Mon 28 Oct 2013 07:33:59 PM UTC, comment #15: 

I checked in the following changeset for the OCTAVE_HOME problem:

http://hg.savannah.gnu.org/hgweb/octave/rev/136a9e27256e

John W. Eaton <jwe>
Group administrator
Mon 28 Oct 2013 05:54:42 PM UTC, comment #14: 

The fntests.log file should be created in whatever is your current directory when you run _run_test_suite_.

Yes, I already noticed the problem with OCTAVE_HOME substitution.  The problem is that main.cc doesn't have the code to automatically detect the current installation directory to set OCTAVE_HOME.  It is just looking in the environment for OCTAVE_HOME.  I'll see if I can fix that so it is detected automatically.

John W. Eaton <jwe>
Group administrator
Mon 28 Oct 2013 05:46:43 PM UTC, comment #13: 

Reporting test results poses a problem as fntests.log is nowhere to be found.
In an (MXE-cross) octave build from yesterday I found it in the OCTAVE_HOME subdir (i.e., "root dir") itself. But in today's build (hg id see above) it seems it isn't created.

A more positive thing is that I saw no makeinfo issues.
In the %TEMP% dir I found loads of octave-help-<random string> files, all containing \texinfo text. Based on their time stamp I think these are made during _run_test_suite_ operation.

Anyway, from the messages scrolling by on XP I see 39 FAILS and on Win 7 37; no idea why that is different. The fntests.log from yesterday's build shows:

- conv2.cc yields 7 FAILS (also on Linux)
- bug38236 yields 1 FAIL (also on Linux; "vr undefined")
MinGW-specific (i.e., not seen on Linux):
- data.cc 4 FAILS (Inf vs NaN as usual on MinGW)
- quadgk: max_recursion_depth exceeded
- classdef (20 FAILs) - wonder why it counts those on a non-classdef build
- system.cc: file attributes (always fails on MinGW as Windows file attributes are different)
- syscalls.cc: AFAICS CRLF versus LF line ending issues
- assert.m: some less easily diagnosed FAILs
plus a few more (no time now to scrutinize the fntests.log).

Usually MinGW builds have 10-12 FAILS; discounting the 20 classdef ones there are now a few more (assert, quadgk, syscalls). Hopefully I can have a look at those by the end of this week.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 28 Oct 2013 04:51:57 PM UTC, comment #12: 

An MXE (cross-)built octave.exe (17780:8b353af4a1ca) won't start the GUI on my WinXP & Win7 systems.
octave-gui.exe itself works OK AFAICS.
On Win7 I get:


c:\Octave\octave-2013-10-28-15-50\bin>octave
octave: failed to exec '\home\philip\devel\octdev\mxe-new\mxe-octave\usr\i686-pc-mingw32\bin\octave-gui'


==> Looks like this is again a build-versus-install path problem a la bug #40284.

I'll try to run tests & report on that later.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 28 Oct 2013 04:22:51 PM UTC, comment #11: 

The new options-usage.h file is in the hg archive but I listed it in the wrong place in libinterp/Makefile.am so it didn't appear in the tarball.  That problem should be fixed in hg now.

John W. Eaton <jwe>
Group administrator
Mon 28 Oct 2013 12:29:32 PM UTC, comment #10: 

Trying to compile a native mingw version to see if it works with ALL the latest commits :) ...

Under my native build I always get complaints/errors about not being able to build the documentation due to missing tex stuff - unless I am compiling a dist version, which usually works ok.

John Donoghue <lostbard>
Group Member
Mon 28 Oct 2013 10:29:14 AM UTC, comment #9: 

I will take that back - it did not compile.

make[5]: * No rule to make target `options-usage.h', needed by `all-am'.  Stop.
make[5]: * Waiting for unfinished jobs....
mv dldfcn/tsearch.cc-tst-t dldfcn/tsearch.cc-tst
/home/jade/mxe-octave/tmp-octave/octave-3.7.7+/libinterp/octave.cc:68:27: fatal error: options-usage.h: No such file or directory
 #include "options-usage.h"
                           ^
compilation terminated.

John Donoghue <lostbard>
Group Member
Mon 28 Oct 2013 10:25:47 AM UTC, comment #8: 

I compiled octave id b5d58667d32d last night successfully with the latest mxe (patcahed for the 3.7.7+ number and checksum change) and it compiled ok.

I havent tried running it yet, but will when I get the chance.

Unfortunately I will be out for a day or two and will only have the ability to compile/run native mingw code until I get back.

John Donoghue <lostbard>
Group Member
Mon 28 Oct 2013 06:49:12 AM UTC, comment #7: 

I tried building current Octave (hg id = 8b353af4a1ca) with mxe-octave (hg id = e7cb2340feff+; changes only in the version number and sha1sum for the Octave tar file that I generated). 

When I copy the resulting binary to my Windows 7 system and run _run_test_suite_, it fails a number of tests, some with a message about not finding makeinfo not recognized as an internal or external command, operable program, or batch file.  But system ("makeinfo --version") displays the makeinfo version info as expected.

This message doesn't show up until later in the tests, so I thought maybe we were accumulating open files or something similar that was preventing Octave from opening program files to run.  So I tried running only the fixed tests, but that doesn't seem to avoid the problem.

Then I tried running Octave from inside an msys terminal window after setting PATH as suggested and it crashes with a segfault in the fsolve test.

I'm also noticing a number of times when the GUI appears to hang and I get a spinning cursor.  It usually comes back after 5-10 (or maybe more) seconds, but I have no idea what is going on during the delay.

Ugh, we can't release like this...

John W. Eaton <jwe>
Group administrator
Sun 27 Oct 2013 06:57:49 PM UTC, comment #6: 

See the post I was referring to - Octave's GUI crashes when closing from the main menu (File | Exit).
Ctrl-d never gave issues.

BTW since a few weeks I also need a batch file (to add <OCTAVE_HOME>/bin to the PATH for the newest Octave development versions; indeed to be able to run mkoctfile, unzip, gzip, etc.).

Until that time I just started octave-3.7.7+.exe directly and then somehow the /bin subdir always automagically got added to the end of the Windows PATH of Octave's process (as per getenv("PATH"); sometimes it even got added twice). I didn't investigate further.

Older Octave vesions on Windows didn't require a batch file either, at least until 3.6.4, nor Michaels 3.7.2+ MSVC snapshot binary. In this respect it is remarkable that newer versions do need one. The putenv() messages you see could be related (though that may be a red herring).

Philip Nienhuis <philipnienhuis>
Group Member
Sun 27 Oct 2013 06:06:43 PM UTC, comment #5: 

maybe - how were you running octave? I havent been able to cause it to crash since running from a bat file.

I couldn't get ctrl-d to lock up running either way. (lately at least)

John Donoghue <lostbard>
Group Member
Sun 27 Oct 2013 05:26:52 PM UTC, comment #4: 

As to the crashes in comment #1, could this question by me from two weeks ago be related?

https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2013-October/036864.html

(No bug report at the time as I couldn't pinpoint it down exactly. But it used to be consistent behavior.)

Philip Nienhuis <philipnienhuis>
Group Member
Sun 27 Oct 2013 01:05:02 PM UTC, comment #3: 

If I run octave from a .bat file (in windows as needed for mkoctfile etc to work correctly), then the issue goes away and everything appears to work.


John Donoghue <lostbard>
Group Member
Sun 27 Oct 2013 12:28:56 PM UTC, comment #2: 

If this happens with the cross build but not the native build, then I suspect that there is some difference in configuration that causes the problem.  Probably in one case you are getting the gnulib setenv code and the other you are not.  Can you determine whether that is happening?

John W. Eaton <jwe>
Group administrator
Sat 26 Oct 2013 06:17:10 PM UTC, comment #1: 

Actually, it looks to be intermittent. Sometimes it will display error: putenv: Not enough space when running setenv.

Other times setenv and getenv works.


It does appear that after setenv works and I go to close the GUI, octave crashes.

As mentioned before, this doesn't occur with my native build version of the code.

John Donoghue <lostbard>
Group Member
Sat 26 Oct 2013 05:49:31 PM UTC, original submission:  


Using the latest dev 3.7.7+ (25-Oct-13) cross compiled with latest mxe octave base and installed on a Win 7 machine.


>> getenv('CC')
ans =
>> setenv('CC', 't')
>> getenv('CC')
ans =
>>
+verbatim+

Interestingly, a native built (on the Win 7 machine) version of the same octave sources works as expected, and changes CC (or whatever name is set/gotten).


John Donoghue <lostbard>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #29584:  test.diff added by lostbard (7KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by lostbard (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-11-13 rik5 StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2013-11-10 lostbard Attached File- Added test.diff, #29584
    2013-11-08 rik5 StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code