Could not read file classpath txt matlab ошибка

The proof for the later (need for -javadir) has been for this side this one:

(Apr 22, 2013 17:09:06) ##################################################################
(Apr 22, 2013 17:09:06) #
(Apr 22, 2013 17:09:06) # Today's Date:
(Apr 22, 2013 17:09:06) Mon Apr 22 17:09:06 CEST 2013
(Apr 22, 2013 17:09:06)
(Apr 22, 2013 17:09:06) System Info
(Apr 22, 2013 17:09:06) OS: Linux 2.6.32-5-amd64
(Apr 22, 2013 17:09:06) Arch: amd64
(Apr 22, 2013 17:09:06) Data Model: 64
(Apr 22, 2013 17:09:06) Language: en
(Apr 22, 2013 17:09:06) Java Vendor: Sun Microsystems Inc.
(Apr 22, 2013 17:09:06) Java Home: /tmp/mathworks_26936/sys/java/jre/glnxa64/jre
(Apr 22, 2013 17:09:06) Java Version: 1.6.0_17
(Apr 22, 2013 17:09:06) Java VM Name: Java HotSpot(TM) 64-Bit Server VM
(Apr 22, 2013 17:09:06) Java Class Path: .
(Apr 22, 2013 17:09:06) User Name: sw
(Apr 22, 2013 17:09:06) Current Directory: /dev/shm/MATLAB/2013a/dummy-dummy/2013a
(Apr 22, 2013 17:09:06) Input arguments:
(Apr 22, 2013 17:09:06) root /dev/shm/MATLAB/2013a/dummy-dummy/2013a
(Apr 22, 2013 17:09:06) tmpdir /tmp/mathworks_26936
(Apr 22, 2013 17:09:06) inputFile /dev/shm/MATLAB/2013a/dummy-dummy/my_installer_input.txt
(Apr 22, 2013 17:09:06) standalone true
(Apr 22, 2013 17:09:06) Input file:
##################################################################

Funnily, the heapmem related value that is picked up instead is: -Xmx512m:

sw       27312  0.0  0.0   9116  1284 pts/0    S+   17:34   0:00  |                               _ /bin/bash -c export _JAVA_OPTIONS="-Xmx128M"; ./install -v -inputFile /dev/shm
sw       27313  0.0  0.0   3960   684 pts/0    S+   17:34   0:00  |                                   _ /bin/sh ./install -v -inputFile /dev/shm/MATLAB/2013a/dummy-dummy/my_insta
sw       27354 55.5  1.2 729072 307080 pts/0   Sl+  17:34   0:41  |                                       _ /tmp/mathworks_27313/sys/java/jre/glnxa64/jre/bin/java -Xmx512m -Djava

while the real jre picked up is, the one coming with matlab itself;

Folks, can you confirm what is the case with 2012b?
Could it be divergence across the two versions I’m hitting against?

The answer is important in relation to what kind of patch is the right one for this!

So, as part of this issue, fix:

1. Bail out when build is not correct (quick fix: detect classpath.txt; more elaborate fix: inspect errorlevels)

2. Use p7zip so that no intermediary tarball generation step is required, by extracting directly from the .iso:

• hack and beatify https://raw.github.com/fgeorgatos/easybuild.experimental/master/contrib/pkgsrc/20121226/p/p7zip_9.20.1_src_all.eb
• make all2 target would provide 7z, then can do:
• …/p7zip_9.20.1/bin/7z x …/R2013a_UNIX_MAC.iso

1. Logfiles: «default file output is in user’s home directory», this should be tunable towards ~/.local/matlab_jre via:
   sys/java/jre/glnxa64/jre/lib/logging.properties -> java.util.logging.FileHandler.pattern = %h/java%u.log

2. _JAVA_OPTIONS should be tunable from within easyconfig; also, despite that the Java dependency gets loaded, I can testify that that version is not really picked up by MATLAB neither at build- nor at run-time! Fix via -javadir?

3. there is one slash too many in the final path, strip it from: ['/sbin']

4. permit preinstallopts, installopts for generality and all-around-hackability

5. copy also file /tmp/mathworks_sw.log because it may hold useful clues as regards failure modes (btw. this is a conflict point if installing multiple versions of MATLAB in parallel, under same user — take a note)

6. consider ways to automate (or not) the passing of variables like -singleCompThread as everybody else is doing, so that MATLAB is a bit clueful in a shared system; perhaps provide a generic wrapper script? ref: [1] [2] [3] [4] [5] [6]

Ref: #106 «Ported support for installing MATLAB» # original issue

[1] https://wiki.hpcc.msu.edu/display/Issues/MATLAB+overutilizing+CPUS
[2] https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToRunMatlab
[3] http://www.hpc.maths.unsw.edu.au/tensor/matlab
[4] http://wiki.rac.manchester.ac.uk/community/MatlabWithCondor
[5] http://igrida.gforge.inria.fr/faq.html#how-to-use-matlab
[6] http://www.osc.ox.ac.uk/content/running-matlab

The reported error is persisting, even when installing from ramdisk (/dev/shm) to an SSD disk (/tmp),
although the later increases the chances of success.
Interestingly, the exact failure mode varies but it always appears memory related and around the same point, like:

(Apr 23, 2013 16:43:19) Installing Product: Symbolic Math Toolbox 5.10
(Apr 23, 2013 16:43:50) java.lang.OutOfMemoryError: GC overhead limit exceeded
        at java.nio.channels.Channels$ReadableByteChannelImpl.read(Unknown Source)
        at sun.nio.ch.FileChannelImpl.transferFromArbitraryChannel(Unknown Source)

Yet, we already have some progress on this front:

• Running install with DISPLAY unset, outside of easybuild and with _JAVA_OPTIONS upgraded seem to cure it.
  Most likely will track it down.

1. so, sanity_check_step would benefit from an exact check on file toolbox/local/classpath.txt

2. indeed, the following prototype code seems to do the trick; do we want to make the .iso as the source now?

sources = [
    'p7zip_9.20.1_x86_linux_bin.tar.bz2',
    ('R%s_UNIX_MAC.iso' % version, './p7zip_9.20.1/bin/7z x %s && chmod -R u+wx .'),
    ]
source_urls = ['http://downloads.sourceforge.net/project/p7zip/p7zip/9.20.1']

…an upcoming PR will address much of this issue… stay on standby.

So, question to the experts:

• regardless of tuning style, jre co-bundled with MATLAB is part of the build no matter what, as visible below; I see no knobs to tune it, therefor I suggest to completely let go with Java as dependent module of MATLAB

Agreed? that would kick out a few lines from the installer logic and keep things more tidy.
(and not go against the reproducibility argument, because jre is part of the bundle anyhow)

_JAVA_OPTIONS="-Xmx512m" is recommended at both install and run-time… comments?

>> ver
-------------------------------------------------------------------------------------------------------
MATLAB Version: 8.1.0.604 (R2013a)
MATLAB License Number: 886910
Operating System: Linux 2.6.32-5-amd64 #1 SMP Fri Feb 15 15:39:52 UTC 2013 x86_64
Java Version: Java 1.6.0_17-b04 with Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM mixed mode
-------------------------------------------------------------------------------------------------------

Summary of the upcoming PRs & indirectly replying to Kenneth’s feedback above:

• 176 bugfix matlab #181 # rewire and generalize easyblock
• 176 bugfix contrib matlab 2013a easybuild-easyconfigs#234 # easyconfig for both 2012b & 2013a

1. Bail out when build is not correct (quick fix: detect classpath.txt; more elaborate fix: inspect errorlevels)

Done, by explicitly now inspecting for classpath.txt

The incorrect builds were caused by exhausting the heap, which apparently was more probable on slower filesystems (!). Quadrapling the heap via _JAVA_OPTIONS seems to make the error go away; N.B. the error
was manifesting itself in non-deterministic manner, ie. different toolboxes would install at different runs.

1. Use p7zip so that no intermediary tarball generation step is required, by extracting directly from the .iso:

7z does the magic directly form the .iso and, it is employed in the 2013a, for now.
The use of a binary tarball is fully intentional, because a dependency is not available at fetch/extract time

1. Logfiles: «default file output is in user’s home directory», this should be tunable towards ~/.local/matlab_jre via:
   sys/java/jre/glnxa64/jre/lib/logging.properties -> java.util.logging.FileHandler.pattern = %h/java%u.log

N/A ; ignored for now; doable via patchfile; suggestion for HPC environments: /tmp/%h/java%u.log

1. _JAVA_OPTIONS should be tunable from within easyconfig; also, despite that the Java dependency gets loaded, I can testify that that version is not really picked up by MATLAB neither at build- nor at run-time! Fix via -javadir?

OK, tried all the possible alternatives; judicium: drop dependency on Java/1.7 altogether;
It is the cleaner solution of all, because MATLAB provides the JRE on both install & run-time
(in fact, in the later case, there seems to be no non-hack way to modify it)

N.B. -javadir does work when defined at build time, but only that; as such it is pointless to keep.

1. there is one slash too many in the final path, strip it from: [‘/sbin’]

Let easybuild do the magic right, by simply creating the directory.

1. permit preinstallopts, installopts for generality and all-around-hackability

Done, and makes things much cleaner.

1. copy also file /tmp/mathworks_sw.log because it may hold useful clues as regards failure modes (btw. this is a conflict point if installing multiple versions of MATLAB in parallel, under same user — take a note)

N/A; TBD.

1. consider ways to automate (or not) the passing of variables like -singleCompThread as everybody else is doing, so that MATLAB is a bit clueful in a shared system; perhaps provide a generic wrapper script?

N/A; this is very desirable feature but out of scope for this issue.
fyi. it relates to HPCBIOS defined variables of the BC_ family:
http://hpcbios.readthedocs.org/en/latest/HPCBIOS_2012-98.html
Alas, it requires more elaborate definitions of things like HT, MPI ranks, using parallel etc