Why do I receive a java.log error when launching MATLAB R12.X on Linux?

When starting MATLAB R12.x on Linux, MATLAB might abort at startup and create a Java log. For example:

ERROR: Opening Log file:  /home/greg/java.log.24256
Aborted

There may also be a splash screen followed by a segmentation violation, and a java log dump.

ERROR: Opening log file: <dir>/java.log.$$
Aborted.


SIGSEGV   11*  segmentation violation
stackbase=BFFFAD58, stackpointer=BFFF9124

Full thread dump:
    "SIGQUIT handler" (TID:0x420752a0, sys_thread_t:0x8193a60, state:R, thread_t: t@2051, sp:0x0
 threadID:0x311e, stack_base:0xbf5ffa80, stack_size:0x200000) prio=1085475358
    "Finalizer thread" (TID:0x42075088, sys_thread_t:0x817e2d0, state:CW, thread_t: t@1026, sp:0x0
 threadID:0x311d, stack_base:0xbf7ffa80, stack_size:0x200000) prio=1085475358
    "main" (TID:0x420750b0, sys_thread_t:0x8183560, state:R, thread_t: t@1024, sp:0x0 threadID:0x302a,
 stack_base:0xbfffad58, stack_size:0x200000) prio=1085475358 *current thread*
java.lang.System.initializeSystemClass(System.java)
Monitor Cache Dump:
Registered Monitor Dump:
    Thread queue lock: <unowned>
    Name and type hash table lock: <unowned>
    String intern lock: <unowned>
    JNI pinning lock: <unowned>
    JNI global reference lock: <unowned>
    BinClass lock: <unowned>
    Class loading lock: <unowned>
    Java stack lock: <unowned>
    Code rewrite lock: <unowned>
    Heap lock: <unowned>
    Has finalization queue lock: <unowned>
    Finalize me queue lock: <unowned>
Waiting to be notified:
    "Finalizer thread" (0x817e2d0)
    Monitor registry: owner "main" (0x8183560, 1 entry)

Answer 1

[MathWorks Support Team]

The problem has been noted on, but is not limited to, Slackware 7 and Debian 2.2 and 3.0 (Woody).

The Java log file indicates that the virtual machine fails. This most likely indicates that your Linux machine is missing the en_US locale, which the Blackdown Java VM requires for some character conversion operations. Typically, this file would be found in /usr/share/locale/en_US, though it may vary from one glibc install to another.

Normally, most of the major distributions install this file for you. However, if you are building your own glibc, please see the comments in the INSTALL file. In particular, pay attention to the comments on setting up particular locales and/or installing all locales supported by glibc. If you are using a major distribution and you experience this problem, ask the maintainers of that distribution, which package might contain the en_US locale.

Note: Without the locale en_US in place, MATLAB will still work using the -nojvm option at startup. In addition, simple Java programs (run outside of MATLAB) will fail with the same error.

On Debian 3.0 (Woody), the problem may still exist if the en_US locale is installed. To avoid this problem, reconfigure the installed locales package with the command "dpkg-reconfigure locales". When asked which locales to install, be sure your selection includes the en_US locale.

Some customers have reported that the following steps will fix the problem:

First, go to the directory where you configured your glibc. This would be the directory that contains the glibc file, for example, glibc-2.2.5. Then execute the following command to choose the appropriate en_US locale:

make localedata/install-locales

Another customer has reported that using the following commands/steps on Debian fixed the problem:

1.  apt-get install locales -y

2.  dpkg-reconfigure -plow locales  
   This command is only needed because the locales had been previously installed with no
   specific locales included


3.  Choose the following locales for inclusion:

en_US ISO-8859-1
en_US.ISO-8859-15 ISO-8859-15
en_US.UTF-8 UTF-8

   Leave the default as "C"