Thread: Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

Brought to you by: oub, zappo

matlab-emacs-discuss

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Greenwood, E. (LARC-D314) <eri...@na...> - 2016-10-28 21:00:58

Hi all,

I’ve been experiencing the same issue with Matlab R2016b on 10.10.  This
issue occurs when launching R2016b from within any version of Emacs.  As
Cumhur reported, all previous versions of Matlab seem to work fine.  It
doesn’t matter how Matlab is launched from within Emacs; as such, this
isn’t really a matlab-emacs mode issue, but I’m hopeful someone else will
have found a solution!

Best Regards,
Eric Greenwood

-----Original Message-----

Hi, thanks for the great matlab emacs, I have been using since R2011a all
the way to R2016a.


I’ve recently updated to Matlab R2016b, and I get a segfault, sometimes
accompanied with the message below (and sometimes not).

objc[761]: Class JavaLaunchHelper is implemented in both
/Applications/MATLAB_R2016b.app/sys/java/jre/maci64/jre/bin/java and
/Applications/MATLAB_R2016b.app/sys/java/jre/maci64/jre/lib/jli/libjli.dyli
b. One of the two will be used. Which one is undefined.

M-Shell segmentation fault: 11

I can launch Matlab R2016b fine from the command line.

Does anybody else get this? Any hints to avoid? ATM, I am keeping both
R2016a (works with emacs matlab) and (works as a stand alone).

Best wishes — Cumhur

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Peter M. <pet...@gm...> - 2016-11-11 03:37:16

Yes, I'm seeing this problem, too.  Mathworks won't touch it, as it does
seem to be a real third party issue with Emacs.

I'm having the problem with OSX 10.12 and Emacs 25.1.1, although it was
also present with my previous emacs (24.5?).

I checked the environment variables, and the only thing I see significantly
different is that emacs shell reports as TERM=dumb, while the Xquartz one
is TERM=xterm and apple's terminal is TERM=xterm-256color.

In all cases, the actual shell is /bin/bash.  I'm guessing this has
something to do with how emacs is setting up the shell, but I can't figure
out what the issue is, exactly.  May be time to cross post to emacs
developers.

Peter

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Eric L. <Eri...@ma...> - 2016-11-14 22:38:55

Hi all,

I’ve been poking at this crash with a co-worker who is more familiar with the java infrastructure in MATLAB than I am.  We’ve been able to reproduce a crash, but not quite as described in the threads I’ve seen.   We were going to try Java 8 next, but haven’t gotten that far.

Anyone who wants to try that can see how to do a JVM update at this link:
https://www.mathworks.com/matlabcentral/answers/103056-how-do-i-change-the-java-virtual-machine-jvm-that-matlab-is-using-for-mac-os

Eric

From: Peter Mao [mailto:pet...@gm...]
Sent: Thursday, November 10, 2016 10:37 PM
To: mat...@li...
Subject: Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

Yes, I'm seeing this problem, too.  Mathworks won't touch it, as it does seem to be a real third party issue with Emacs.
I'm having the problem with OSX 10.12 and Emacs 25.1.1, although it was also present with my previous emacs (24.5?).
I checked the environment variables, and the only thing I see significantly different is that emacs shell reports as TERM=dumb, while the Xquartz one is TERM=xterm and apple's terminal is TERM=xterm-256color.
In all cases, the actual shell is /bin/bash.  I'm guessing this has something to do with how emacs is setting up the shell, but I can't figure out what the issue is, exactly.  May be time to cross post to emacs developers.
Peter

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Peter M. <pet...@gm...> - 2016-11-14 16:18:32

Further evidence (I hope this helps someone solve the problem):

1. 2016b works in NONE of the emacs terminals: shell, term or e-shell.
2. 2016b works fine (even with -nodesktop) from Xquartz's xterm or OSX's
terminal
3. 2016a works fine in emacs
4. Running diff on the java directories (where the potentially offending
files reside) shows NO difference between 2016a and 2016b!
    $ diff -ur /Applications/MATLAB_R2016b.app/sys/java
/Applications/MATLAB_R2016a.app/sys/java

This might not be a Java issue.

On Thu, Nov 10, 2016 at 7:37 PM, Peter Mao <pet...@gm...> wrote:

> Yes, I'm seeing this problem, too.  Mathworks won't touch it, as it does
> seem to be a real third party issue with Emacs.
>
> I'm having the problem with OSX 10.12 and Emacs 25.1.1, although it was
> also present with my previous emacs (24.5?).
>
> I checked the environment variables, and the only thing I see
> significantly different is that emacs shell reports as TERM=dumb, while the
> Xquartz one is TERM=xterm and apple's terminal is TERM=xterm-256color.
>
> In all cases, the actual shell is /bin/bash.  I'm guessing this has
> something to do with how emacs is setting up the shell, but I can't figure
> out what the issue is, exactly.  May be time to cross post to emacs
> developers.
>
> Peter
>

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Eric L. <Eri...@ma...> - 2016-12-01 16:28:28

Hi all,

We identified that MATLAB on the MAC platform can be reproduced with a similar output to what has been noted here with:

matlab -nodisplay -nojvm

In this case, the line:

matlab.internal.supportPackages.addInstalledSupportPackagesToPath

in matlabrc.m is the culprit.  If you don’t have support packages installed, and if you have write permission to your MATLAB install, you can probably comment out this line to have MALTAB get past this step.

I haven’t tested this (I don’t have a Mac) and the developer who found this isn’t an Emacs person, so I’m speculating about this workaround.

Eric

From: Peter Mao [mailto:pet...@gm...]
Sent: Monday, November 14, 2016 11:18 AM
To: mat...@li...
Subject: Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

Further evidence (I hope this helps someone solve the problem):
1. 2016b works in NONE of the emacs terminals: shell, term or e-shell.
2. 2016b works fine (even with -nodesktop) from Xquartz's xterm or OSX's terminal
3. 2016a works fine in emacs
4. Running diff on the java directories (where the potentially offending files reside) shows NO difference between 2016a and 2016b!
    $ diff -ur /Applications/MATLAB_R2016b.app/sys/java /Applications/MATLAB_R2016a.app/sys/java
This might not be a Java issue.

On Thu, Nov 10, 2016 at 7:37 PM, Peter Mao <pet...@gm...<mailto:pet...@gm...>> wrote:
Yes, I'm seeing this problem, too.  Mathworks won't touch it, as it does seem to be a real third party issue with Emacs.
I'm having the problem with OSX 10.12 and Emacs 25.1.1, although it was also present with my previous emacs (24.5?).
I checked the environment variables, and the only thing I see significantly different is that emacs shell reports as TERM=dumb, while the Xquartz one is TERM=xterm and apple's terminal is TERM=xterm-256color.
In all cases, the actual shell is /bin/bash.  I'm guessing this has something to do with how emacs is setting up the shell, but I can't figure out what the issue is, exactly.  May be time to cross post to emacs developers.
Peter

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Peter M. <pet...@gm...> - 2016-11-15 16:02:58

Hi Eric,

I'm glad to see that you're on this problem.  I couldn't get any interest
from emacs-devel.

Please see below -- I'm running 2016a right now under emacs, and it mostly
behaves fine.  Diff-ing the sys/java directories, I see no differences!  Is
it possible that this is not a java issue?  I can't make heads or tails of
the segmentation fault stack trace.

I'll try the java 8 patch if I can find the time today.

Peter

On Mon, Nov 14, 2016 at 8:18 AM, Peter Mao <pet...@gm...> wrote:

> Further evidence (I hope this helps someone solve the problem):
>
> 1. 2016b works in NONE of the emacs terminals: shell, term or e-shell.
> 2. 2016b works fine (even with -nodesktop) from Xquartz's xterm or OSX's
> terminal
> 3. 2016a works fine in emacs
> 4. Running diff on the java directories (where the potentially offending
> files reside) shows NO difference between 2016a and 2016b!
>     $ diff -ur /Applications/MATLAB_R2016b.app/sys/java
> /Applications/MATLAB_R2016a.app/sys/java
>
> This might not be a Java issue.
>
>

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Peter M. <pet...@gm...> - 2016-11-15 16:42:15

still crashing with JAVA_VERSION="1.8.0_111"

$ export MATLAB_JAVA="/Library/Internet
Plug-Ins/JavaAppletPlugin.plugin/Contents/Home"
$ printenv MATLAB_JAVA
/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
$ /Applications/MATLAB_R2016b.app/bin/matlab -nodesktop
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
MaxPermSize=128m; support was removed in 8.0

                                             < M A T L A B (R) >
                                   Copyright 1984-2016 The MathWorks, Inc.
                                    R2016b (9.1.0.441655) 64-bit (maci64)
                                              September 7, 2016


To get started, type one of these: helpwin, helpdesk, or demo.
For product information, visit www.mathworks.com.

objc[16791]: Class JavaLaunchHelper is implemented in both
/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java
(0x107e6f4c0) and
/Applications/MATLAB_R2016b.app/sys/java/jre/maci64/jre/lib/jli/libjli.dylib
(0x1298a7480). One of the two will be used. Which one is undefined.

------------------------------------------------------------------------
       Segmentation violation detected at Tue Nov 15 08:36:47 2016
------------------------------------------------------------------------

Configuration:
  Crash Decoding      : Disabled - No sandbox or build area path
  Crash Mode          : continue (default)
  Current Graphics Driver: Unknown hardware
  Current Visual      : Quartz
  Default Encoding    : ISO-8859-1
  Deployed            : false
  Host Name           : papplebon.local
  MATLAB Architecture : maci64
  MATLAB Entitlement ID: 1475331
  MATLAB Root         : /Applications/MATLAB_R2016b.app
  MATLAB Version      : 9.1.0.441655 (R2016b)
  OpenGL              : hardware
  Operating System    : Darwin 16.0.0 Darwin Kernel Version 16.0.0: Mon Aug
29 17:56:20 PDT 2016; root:xnu-3789.1.32~3/RELEASE_X86_64 x86_64
  Processor ID        : x86 Family 6 Model 58 Stepping 9, GenuineIntel
  Virtual Machine     : Java 1.8.0_111-b14 with Oracle Corporation Java
HotSpot(TM) 64-Bit Server VM mixed mode
  Window System       : Quartz

Fault Count: 1


Abnormal termination:
Segmentation violation

Register State (from fault):
  RAX = 00007fffc244be00  RBX = 00000001119815dd
  RCX = 00000000000000fa  RDX = 0000000111981356
  RSP = 0000700001044280  RBP = 0000700001044290
  RSI = 00000001000004ff  RDI = 000000000000000e

   R8 = 00000001118fbbae   R9 = 0000000000000000
  R10 = 00000001119a0740  R11 = 00007f9483496501
  R12 = 00007000010443e0  R13 = 00007f9483038040
  R14 = 0000000111a8b738  R15 = 0000000111aa4de0

  RIP = 00007f94834965c0  RFL = 0000700001044334

   CS = 0000700001044330   FS = 0000700001044320   GS = 0000000000000000

Stack Trace (from fault):
[  0] 0x000000010eb6ed04
/Applications/MATLAB_R2016b.app/bin/maci64/libmwfl.dylib+00036100
_ZN2fl4diag15stacktrace_base7captureERKNS0_14thread_contextEm+00000052
[  1] 0x000000010eb71f9a
/Applications/MATLAB_R2016b.app/bin/maci64/libmwfl.dylib+00049050
_ZN2fl4test17terminate_handledEv+00000810
[  2] 0x000000010eb71a09
/Applications/MATLAB_R2016b.app/bin/maci64/libmwfl.dylib+00047625
_ZN2fl4diag13terminate_logEPKcPK17__darwin_ucontext+00000185
[  3] 0x0000000111ae6ba8
/Applications/MATLAB_R2016b.app/bin/maci64/libmwmcr.dylib+00420776
_Z32mnRunPathDependentInitializationN6mlutil10contextmgr5McrIDE+00003016
[  4] 0x0000000111ae64e0
/Applications/MATLAB_R2016b.app/bin/maci64/libmwmcr.dylib+00419040
_Z32mnRunPathDependentInitializationN6mlutil10contextmgr5McrIDE+00001280
[  5] 0x0000000111ae4f7a
/Applications/MATLAB_R2016b.app/bin/maci64/libmwmcr.dylib+00413562
mnFatalSignalHandler+00000154
[  6] 0x00007fffc3a3dbba
/usr/lib/system/libsystem_platform.dylib+00011194 _sigtramp+00000026
[  7] 0x000000011191544a
/Applications/MATLAB_R2016b.app/bin/maci64/libmwiqm.dylib+00185418
_ZN5boost4bindIbN3iqm22IntermediatePacketInfoERKNSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEENS_3argILi1EEES9_EENS_3_bi6bind_tIT_NS_4_mfi4cmf1ISG_T0_T1_EENSE_9list_av_2IT2_T3_E4typeEEEMSJ_KFSG_SK_ESN_SO_+00002378
[  8] 0x0000000111a8b467
/Applications/MATLAB_R2016b.app/bin/maci64/libmwmcr.dylib+00046183
_ZN5boost11unique_lockINS_5mutexEE4lockEv+00000039
[  9] 0x0000000111a8c543
/Applications/MATLAB_R2016b.app/bin/maci64/libmwmcr.dylib+00050499
_ZN5boost18condition_variable4waitERNS_11unique_lockINS_5mutexEEE+00000083
[ 10] 0x0000000111a8b3db
/Applications/MATLAB_R2016b.app/bin/maci64/libmwmcr.dylib+00046043
_ZN5boost6detail17shared_state_base13wait_internalERNS_11unique_lockINS_5mutexEEEb+00000091
[ 11] 0x00007fffc39b49d1
/usr/lib/system/libsystem_malloc.dylib+00014801
tiny_malloc_from_free_list+00000431
[ 12] 0x00007fffc39b3522
/usr/lib/system/libsystem_malloc.dylib+00009506
szone_malloc_should_clear+00000400
[ 13] 0x00007fffc39b3332
/usr/lib/system/libsystem_malloc.dylib+00009010 malloc_zone_malloc+00000107
[ 14] 0x00007fffc39b22b0
/usr/lib/system/libsystem_malloc.dylib+00004784 malloc+00000024
[ 15] 0x000000010ebd07d3
/Applications/MATLAB_R2016b.app/bin/maci64/libmwfl.dylib+00436179
_ZN2fl3mem6detail24default_vector_alignmentEv+00011603
[ 16] 0x000000010ed3342c
/Applications/MATLAB_R2016b.app/bin/maci64/libmx.dylib+00005164
_ZN6matrix6detail10noninlined12mx_array_api15mxMallocExCheckEm+00000044
[ 17] 0x0000000114e61210
/Applications/MATLAB_R2016b.app/bin/maci64/libmwlxetypes.dylib+00061968
_ZN9MathWorks3lxe22MxArrayToXvalueTypeMap24GetXvalueTypeFromMxArrayERNS_2ts12iTypeFactoryEPK11mxArray_tag+00000048
[ 18] 0x0000000114e69c87
/Applications/MATLAB_R2016b.app/bin/maci64/libmwlxetypes.dylib+00097415
_ZN9MathWorks3lxe6xvalue19InitializeToMxArrayENSt3__110unique_ptrI11mxArray_tagN6matrix6detail17mxDestroy_deleterEEE+00000071
[ 19] 0x0000000114e69dbd
/Applications/MATLAB_R2016b.app/bin/maci64/libmwlxetypes.dylib+00097725
_ZN9MathWorks3lxe6xvalueC2ENSt3__110unique_ptrI11mxArray_tagN6matrix6detail17mxDestroy_deleterEEE+00000029
[ 20] 0x00000001133a4885
/Applications/MATLAB_R2016b.app/bin/maci64/libmwm_lxe.dylib+10565765
_ZN9MathWorks3lxe14AllocateOutputIZNS0_21AllocateOutputForTempIbLb0EEEvlPNS0_24ElementwiseOperandLayoutEmPmPPPvPbbEUlNS_2ts4TypeEE_EEvPNS0_6xvalueES4_lT_mPKm9mxClassIDb+00000517
[ 21] 0x0000000113379f87
/Applications/MATLAB_R2016b.app/bin/maci64/libmwm_lxe.dylib+10391431
_ZN9MathWorks3lxe29elem_expression_check_anyTypeIbLb0EEEvPv+00000919


If this problem is reproducible, please submit a Service Request via:
    http://www.mathworks.com/support/contact_us/

A technical support engineer might contact you with further information.

Thank you for your help.** This crash report has been saved to disk as
/Users/petermao/matlab_crash_dump.16728-1 **



MATLAB is exiting because of fatal error
Killed: 9

On Tue, Nov 15, 2016 at 8:02 AM, Peter Mao <pet...@gm...> wrote:

> Hi Eric,
>
> I'm glad to see that you're on this problem.  I couldn't get any interest
> from emacs-devel.
>
> Please see below -- I'm running 2016a right now under emacs, and it mostly
> behaves fine.  Diff-ing the sys/java directories, I see no differences!  Is
> it possible that this is not a java issue?  I can't make heads or tails of
> the segmentation fault stack trace.
>
> I'll try the java 8 patch if I can find the time today.
>
> Peter
>
> On Mon, Nov 14, 2016 at 8:18 AM, Peter Mao <pet...@gm...> wrote:
>
>> Further evidence (I hope this helps someone solve the problem):
>>
>> 1. 2016b works in NONE of the emacs terminals: shell, term or e-shell.
>> 2. 2016b works fine (even with -nodesktop) from Xquartz's xterm or OSX's
>> terminal
>> 3. 2016a works fine in emacs
>> 4. Running diff on the java directories (where the potentially offending
>> files reside) shows NO difference between 2016a and 2016b!
>>     $ diff -ur /Applications/MATLAB_R2016b.app/sys/java
>> /Applications/MATLAB_R2016a.app/sys/java
>>
>> This might not be a Java issue.
>>
>>
>

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Eric L. <Eri...@ma...> - 2016-11-15 17:36:06

Thanks Peter,

I’ve forwarded this along.   I’ll let you all know if we learn something.

Eric

From: Peter Mao [mailto:pet...@gm...]
Sent: Tuesday, November 15, 2016 11:42 AM
To: mat...@li...; Eric Ludlam <Eri...@ma...>
Subject: Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

still crashing with JAVA_VERSION="1.8.0_111"

$ export MATLAB_JAVA="/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home"
$ printenv MATLAB_JAVA
/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home
$ /Applications/MATLAB_R2016b.app/bin/matlab -nodesktop
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0

                                             < M A T L A B (R) >
                                   Copyright 1984-2016 The MathWorks, Inc.
                                    R2016b (9.1.0.441655) 64-bit (maci64)
                                              September 7, 2016


To get started, type one of these: helpwin, helpdesk, or demo.
For product information, visit www.mathworks.com<http://www.mathworks.com>.

objc[16791]: Class JavaLaunchHelper is implemented in both /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/java (0x107e6f4c0) and /Applications/MATLAB_R2016b.app/sys/java/jre/maci64/jre/lib/jli/libjli.dylib (0x1298a7480). One of the two will be used. Which one is undefined.

------------------------------------------------------------------------
       Segmentation violation detected at Tue Nov 15 08:36:47 2016
------------------------------------------------------------------------

Configuration:
  Crash Decoding      : Disabled - No sandbox or build area path
  Crash Mode          : continue (default)
  Current Graphics Driver: Unknown hardware
  Current Visual      : Quartz
  Default Encoding    : ISO-8859-1
  Deployed            : false
  Host Name           : papplebon.local
  MATLAB Architecture : maci64
  MATLAB Entitlement ID: 1475331
  MATLAB Root         : /Applications/MATLAB_R2016b.app
  MATLAB Version      : 9.1.0.441655 (R2016b)
  OpenGL              : hardware
  Operating System    : Darwin 16.0.0 Darwin Kernel Version 16.0.0: Mon Aug 29 17:56:20 PDT 2016; root:xnu-3789.1.32~3/RELEASE_X86_64 x86_64
  Processor ID        : x86 Family 6 Model 58 Stepping 9, GenuineIntel
  Virtual Machine     : Java 1.8.0_111-b14 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
  Window System       : Quartz

Fault Count: 1


Abnormal termination:
Segmentation violation

Register State (from fault):
  RAX = 00007fffc244be00  RBX = 00000001119815dd
  RCX = 00000000000000fa  RDX = 0000000111981356
  RSP = 0000700001044280  RBP = 0000700001044290
  RSI = 00000001000004ff  RDI = 000000000000000e

   R8 = 00000001118fbbae   R9 = 0000000000000000
  R10 = 00000001119a0740  R11 = 00007f9483496501
  R12 = 00007000010443e0  R13 = 00007f9483038040
  R14 = 0000000111a8b738  R15 = 0000000111aa4de0

  RIP = 00007f94834965c0  RFL = 0000700001044334

   CS = 0000700001044330   FS = 0000700001044320   GS = 0000000000000000

Stack Trace (from fault):
[  0] 0x000000010eb6ed04 /Applications/MATLAB_R2016b.app/bin/maci64/libmwfl.dylib+00036100 _ZN2fl4diag15stacktrace_base7captureERKNS0_14thread_contextEm+00000052
[  1] 0x000000010eb71f9a /Applications/MATLAB_R2016b.app/bin/maci64/libmwfl.dylib+00049050 _ZN2fl4test17terminate_handledEv+00000810
[  2] 0x000000010eb71a09 /Applications/MATLAB_R2016b.app/bin/maci64/libmwfl.dylib+00047625 _ZN2fl4diag13terminate_logEPKcPK17__darwin_ucontext+00000185
[  3] 0x0000000111ae6ba8 /Applications/MATLAB_R2016b.app/bin/maci64/libmwmcr.dylib+00420776 _Z32mnRunPathDependentInitializationN6mlutil10contextmgr5McrIDE+00003016
[  4] 0x0000000111ae64e0 /Applications/MATLAB_R2016b.app/bin/maci64/libmwmcr.dylib+00419040 _Z32mnRunPathDependentInitializationN6mlutil10contextmgr5McrIDE+00001280
[  5] 0x0000000111ae4f7a /Applications/MATLAB_R2016b.app/bin/maci64/libmwmcr.dylib+00413562 mnFatalSignalHandler+00000154
[  6] 0x00007fffc3a3dbba           /usr/lib/system/libsystem_platform.dylib+00011194 _sigtramp+00000026
[  7] 0x000000011191544a /Applications/MATLAB_R2016b.app/bin/maci64/libmwiqm.dylib+00185418 _ZN5boost4bindIbN3iqm22IntermediatePacketInfoERKNSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEENS_3argILi1EEES9_EENS_3_bi6bind_tIT_NS_4_mfi4cmf1ISG_T0_T1_EENSE_9list_av_2IT2_T3_E4typeEEEMSJ_KFSG_SK_ESN_SO_+00002378
[  8] 0x0000000111a8b467 /Applications/MATLAB_R2016b.app/bin/maci64/libmwmcr.dylib+00046183 _ZN5boost11unique_lockINS_5mutexEE4lockEv+00000039
[  9] 0x0000000111a8c543 /Applications/MATLAB_R2016b.app/bin/maci64/libmwmcr.dylib+00050499 _ZN5boost18condition_variable4waitERNS_11unique_lockINS_5mutexEEE+00000083
[ 10] 0x0000000111a8b3db /Applications/MATLAB_R2016b.app/bin/maci64/libmwmcr.dylib+00046043 _ZN5boost6detail17shared_state_base13wait_internalERNS_11unique_lockINS_5mutexEEEb+00000091
[ 11] 0x00007fffc39b49d1             /usr/lib/system/libsystem_malloc.dylib+00014801 tiny_malloc_from_free_list+00000431
[ 12] 0x00007fffc39b3522             /usr/lib/system/libsystem_malloc.dylib+00009506 szone_malloc_should_clear+00000400
[ 13] 0x00007fffc39b3332             /usr/lib/system/libsystem_malloc.dylib+00009010 malloc_zone_malloc+00000107
[ 14] 0x00007fffc39b22b0             /usr/lib/system/libsystem_malloc.dylib+00004784 malloc+00000024
[ 15] 0x000000010ebd07d3 /Applications/MATLAB_R2016b.app/bin/maci64/libmwfl.dylib+00436179 _ZN2fl3mem6detail24default_vector_alignmentEv+00011603
[ 16] 0x000000010ed3342c /Applications/MATLAB_R2016b.app/bin/maci64/libmx.dylib+00005164 _ZN6matrix6detail10noninlined12mx_array_api15mxMallocExCheckEm+00000044
[ 17] 0x0000000114e61210 /Applications/MATLAB_R2016b.app/bin/maci64/libmwlxetypes.dylib+00061968 _ZN9MathWorks3lxe22MxArrayToXvalueTypeMap24GetXvalueTypeFromMxArrayERNS_2ts12iTypeFactoryEPK11mxArray_tag+00000048
[ 18] 0x0000000114e69c87 /Applications/MATLAB_R2016b.app/bin/maci64/libmwlxetypes.dylib+00097415 _ZN9MathWorks3lxe6xvalue19InitializeToMxArrayENSt3__110unique_ptrI11mxArray_tagN6matrix6detail17mxDestroy_deleterEEE+00000071
[ 19] 0x0000000114e69dbd /Applications/MATLAB_R2016b.app/bin/maci64/libmwlxetypes.dylib+00097725 _ZN9MathWorks3lxe6xvalueC2ENSt3__110unique_ptrI11mxArray_tagN6matrix6detail17mxDestroy_deleterEEE+00000029
[ 20] 0x00000001133a4885 /Applications/MATLAB_R2016b.app/bin/maci64/libmwm_lxe.dylib+10565765 _ZN9MathWorks3lxe14AllocateOutputIZNS0_21AllocateOutputForTempIbLb0EEEvlPNS0_24ElementwiseOperandLayoutEmPmPPPvPbbEUlNS_2ts4TypeEE_EEvPNS0_6xvalueES4_lT_mPKm9mxClassIDb+00000517
[ 21] 0x0000000113379f87 /Applications/MATLAB_R2016b.app/bin/maci64/libmwm_lxe.dylib+10391431 _ZN9MathWorks3lxe29elem_expression_check_anyTypeIbLb0EEEvPv+00000919


If this problem is reproducible, please submit a Service Request via:
    http://www.mathworks.com/support/contact_us/

A technical support engineer might contact you with further information.

Thank you for your help.** This crash report has been saved to disk as /Users/petermao/matlab_crash_dump.16728-1 **



MATLAB is exiting because of fatal error
Killed: 9

On Tue, Nov 15, 2016 at 8:02 AM, Peter Mao <pet...@gm...<mailto:pet...@gm...>> wrote:
Hi Eric,
I'm glad to see that you're on this problem.  I couldn't get any interest from emacs-devel.
Please see below -- I'm running 2016a right now under emacs, and it mostly behaves fine.  Diff-ing the sys/java directories, I see no differences!  Is it possible that this is not a java issue?  I can't make heads or tails of the segmentation fault stack trace.
I'll try the java 8 patch if I can find the time today.

Peter

On Mon, Nov 14, 2016 at 8:18 AM, Peter Mao <pet...@gm...<mailto:pet...@gm...>> wrote:
Further evidence (I hope this helps someone solve the problem):
1. 2016b works in NONE of the emacs terminals: shell, term or e-shell.
2. 2016b works fine (even with -nodesktop) from Xquartz's xterm or OSX's terminal
3. 2016a works fine in emacs
4. Running diff on the java directories (where the potentially offending files reside) shows NO difference between 2016a and 2016b!
    $ diff -ur /Applications/MATLAB_R2016b.app/sys/java /Applications/MATLAB_R2016a.app/sys/java
This might not be a Java issue.

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Eric L. <Eri...@ma...> - 2016-12-14 17:19:37

Hello again,

I’ve been watching progress in development around this Mac/Emacs/MATLAB issue.   They have identified that the reason MATLAB is crashing in Emacs, but not on the command line is because Emacs is setting the stack size.  A way to reproduce outside of Emacs is as follows:

ulimit -s 8515
matlab

Stacks limited to sizes of 8512 or more works fine for them.

I looked into stack size within emacs, and saw several references to increasing the stack size to 8519 in Emacs to work around a bug I’m not familiar with, but not to a way to increase the stack size of sub-processes.

Any Emacs hackers on this list familiar with updating stack size for sub-processes in Emacs as a way to work around this problem?
Thanks
Eric

From: Peter Mao [mailto:pet...@gm...]
Sent: Monday, November 14, 2016 11:18 AM
To: mat...@li...
Subject: Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

Further evidence (I hope this helps someone solve the problem):
1. 2016b works in NONE of the emacs terminals: shell, term or e-shell.
2. 2016b works fine (even with -nodesktop) from Xquartz's xterm or OSX's terminal
3. 2016a works fine in emacs
4. Running diff on the java directories (where the potentially offending files reside) shows NO difference between 2016a and 2016b!
    $ diff -ur /Applications/MATLAB_R2016b.app/sys/java /Applications/MATLAB_R2016a.app/sys/java
This might not be a Java issue.

On Thu, Nov 10, 2016 at 7:37 PM, Peter Mao <pet...@gm...<mailto:pet...@gm...>> wrote:
Yes, I'm seeing this problem, too.  Mathworks won't touch it, as it does seem to be a real third party issue with Emacs.
I'm having the problem with OSX 10.12 and Emacs 25.1.1, although it was also present with my previous emacs (24.5?).
I checked the environment variables, and the only thing I see significantly different is that emacs shell reports as TERM=dumb, while the Xquartz one is TERM=xterm and apple's terminal is TERM=xterm-256color.
In all cases, the actual shell is /bin/bash.  I'm guessing this has something to do with how emacs is setting up the shell, but I can't figure out what the issue is, exactly.  May be time to cross post to emacs developers.
Peter

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Rhys T. <e.r...@gm...> - 2016-12-18 09:19:44

Hello,

Is max-lisp-eval-depth what you are looking for?

max-lisp-eval-depth is a variable defined in ‘C source code’.
Its value is 800

   This variable may be risky if used as a file-local variable.

Documentation:
Limit on depth in ‘eval’, ‘apply’ and ‘funcall’ before error.

This limit serves to catch infinite recursions for you before they cause
actual stack overflow in C, which would be fatal for Emacs.
You can safely make it considerably larger than its default value,
if that proves inconveniently small.  However, if you increase it too far,
Emacs could overflow the real C stack, and crash.


Regards,

Rhys

On 14/12/16 16:46, Eric Ludlam wrote:
>
> Hello again,
>
> I’ve been watching progress in development around this 
> Mac/Emacs/MATLAB issue.   They have identified that the reason MATLAB 
> is crashing in Emacs, but not on the command line is because Emacs is 
> setting the stack size.  A way to reproduce outside of Emacs is as 
> follows:
>
> ulimit -s 8515
>
> matlab
>
> Stacks limited to sizes of 8512 or more works fine for them.
>
> I looked into stack size within emacs, and saw several references to 
> increasing the stack size to 8519 in Emacs to work around a bug I’m 
> not familiar with, but not to a way to increase the stack size of 
> sub-processes.
>
> Any Emacs hackers on this list familiar with updating stack size for 
> sub-processes in Emacs as a way to work around this problem?
>
> Thanks
>
> Eric
>
> *From:*Peter Mao [mailto:pet...@gm...]
> *Sent:* Monday, November 14, 2016 11:18 AM
> *To:* mat...@li...
> *Subject:* Re: [Matlab-emacs-discuss] matlab-shell segfaults with 
> matlab R2016b on Mac OS 10.11.6 Emacs 25.1
>
> Further evidence (I hope this helps someone solve the problem):
>
> 1. 2016b works in NONE of the emacs terminals: shell, term or e-shell.
>
> 2. 2016b works fine (even with -nodesktop) from Xquartz's xterm or 
> OSX's terminal
>
> 3. 2016a works fine in emacs
>
> 4. Running diff on the java directories (where the potentially 
> offending files reside) shows NO difference between 2016a and 2016b!
>
>     $ diff -ur /Applications/MATLAB_R2016b.app/sys/java 
> /Applications/MATLAB_R2016a.app/sys/java
>
> This might not be a Java issue.
>
> On Thu, Nov 10, 2016 at 7:37 PM, Peter Mao <pet...@gm... 
> <mailto:pet...@gm...>> wrote:
>
>     Yes, I'm seeing this problem, too.  Mathworks won't touch it, as
>     it does seem to be a real third party issue with Emacs.
>
>     I'm having the problem with OSX 10.12 and Emacs 25.1.1, although
>     it was also present with my previous emacs (24.5?).
>
>     I checked the environment variables, and the only thing I see
>     significantly different is that emacs shell reports as TERM=dumb,
>     while the Xquartz one is TERM=xterm and apple's terminal is
>     TERM=xterm-256color.
>
>     In all cases, the actual shell is /bin/bash.  I'm guessing this
>     has something to do with how emacs is setting up the shell, but I
>     can't figure out what the issue is, exactly.  May be time to cross
>     post to emacs developers.
>
>     Peter
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Matlab-emacs-discuss mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Eric L. <Eri...@ma...> - 2016-12-19 14:35:37

Hi Rhys,

I am referring to the C stack size (the amount of memory allocated for both the stack and variables of a running C program.   In this case MATLAB as a subprocess is being limited in how big it's stack can be because its parent (Emacs) has setup limits for that subprocess.

This can be a useful thing to do if you don't always trust a subprocess, since it will prevent the subprocess from accidentally (or perhaps purposefully) locking up your computer by using up all available memory.

Eric

From: Rhys Thomas [mailto:e.r...@gm...]
Sent: Sunday, December 18, 2016 4:20 AM
To: mat...@li...
Subject: Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1


Hello,

Is max-lisp-eval-depth what you are looking for?

max-lisp-eval-depth is a variable defined in 'C source code'.
Its value is 800

  This variable may be risky if used as a file-local variable.

Documentation:
Limit on depth in 'eval', 'apply' and 'funcall' before error.

This limit serves to catch infinite recursions for you before they cause
actual stack overflow in C, which would be fatal for Emacs.
You can safely make it considerably larger than its default value,
if that proves inconveniently small.  However, if you increase it too far,
Emacs could overflow the real C stack, and crash.

Regards,

Rhys
On 14/12/16 16:46, Eric Ludlam wrote:
Hello again,

I've been watching progress in development around this Mac/Emacs/MATLAB issue.   They have identified that the reason MATLAB is crashing in Emacs, but not on the command line is because Emacs is setting the stack size.  A way to reproduce outside of Emacs is as follows:

ulimit -s 8515
matlab

Stacks limited to sizes of 8512 or more works fine for them.

I looked into stack size within emacs, and saw several references to increasing the stack size to 8519 in Emacs to work around a bug I'm not familiar with, but not to a way to increase the stack size of sub-processes.

Any Emacs hackers on this list familiar with updating stack size for sub-processes in Emacs as a way to work around this problem?
Thanks
Eric

From: Peter Mao [mailto:pet...@gm...]
Sent: Monday, November 14, 2016 11:18 AM
To: mat...@li...<mailto:mat...@li...>
Subject: Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

Further evidence (I hope this helps someone solve the problem):
1. 2016b works in NONE of the emacs terminals: shell, term or e-shell.
2. 2016b works fine (even with -nodesktop) from Xquartz's xterm or OSX's terminal
3. 2016a works fine in emacs
4. Running diff on the java directories (where the potentially offending files reside) shows NO difference between 2016a and 2016b!
    $ diff -ur /Applications/MATLAB_R2016b.app/sys/java /Applications/MATLAB_R2016a.app/sys/java
This might not be a Java issue.

On Thu, Nov 10, 2016 at 7:37 PM, Peter Mao <pet...@gm...<mailto:pet...@gm...>> wrote:
Yes, I'm seeing this problem, too.  Mathworks won't touch it, as it does seem to be a real third party issue with Emacs.
I'm having the problem with OSX 10.12 and Emacs 25.1.1, although it was also present with my previous emacs (24.5?).
I checked the environment variables, and the only thing I see significantly different is that emacs shell reports as TERM=dumb, while the Xquartz one is TERM=xterm and apple's terminal is TERM=xterm-256color.
In all cases, the actual shell is /bin/bash.  I'm guessing this has something to do with how emacs is setting up the shell, but I can't figure out what the issue is, exactly.  May be time to cross post to emacs developers.
Peter





------------------------------------------------------------------------------

Check out the vibrant tech community on one of the world's most

engaging tech sites, SlashDot.org! http://sdm.link/slashdot




_______________________________________________

Matlab-emacs-discuss mailing list

Mat...@li...<mailto:Mat...@li...>

https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Cumhur E. <cum...@gm...> - 2016-12-20 16:32:50

Dear Eric, Rhys, and list

Thanks so much for looking into this. As Eric predicted, I could not get anything by setting max-lisp-eval-depth to a higher or lower value, matlab still crashes.

Today I have downloaded the R2017a Prerelease, the behavior is the same but the crash-report is more varied. 

I have created the following support request at mathworks, I’ll post if I hear something.

Season’s greetings, Cumhur

——	
Since 2016a, MATLAB crashes in Emacs, in matlab-shell or even without using it from any eshell. The developers of matlab-shell have identified that the reason MATLAB is crashing in Emacs, but not on the command line is because Emacs is setting the stack size. It looks like MATLAB has more demands on stack size since 2016a, and Emacs cannot cope with it. We are trying to find a way to increase the stack-size in Emacs, but if not absolutely needed, could you please also decrease the MATLAB needs? This behavior remains in R2017a Prerelease, would be great to find a solution to keep using Emacs as the main editor of MATLAB code. I attach the crash log below. 
---- 


                            < M A T L A B (R) >
                  Copyright 1984-2016 The MathWorks, Inc.
              R2017a Prerelease (9.2.0.494151) 64-bit (maci64)
                              December 1, 2016

 
To get started, type one of these: helpwin, helpdesk, or demo.
For product information, visit www.mathworks.com.
 
Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: com/mathworks/cfbutils/StatEntryReceiver
	at com.mathworks.mwswing.MacAppearanceUtils.getMacAlternateSelectedControlColor(MacAppearanceUtils.java:254)
	at com.mathworks.mwswing.MacAppearanceUtils.setMacAppearanceColors(MacAppearanceUtils.java:229)
	at com.mathworks.mwswing.MacAppearanceUtils.initialize(MacAppearanceUtils.java:41)
	at com.mathworks.mwswing.plaf.PlafUtils.correctMacintoshLookAndFeel(PlafUtils.java:203)
	at com.mathworks.mwswing.plaf.PlafUtils.correctPlatformLookAndFeel(PlafUtils.java:118)
	at com.mathworks.mwswing.plaf.PlafUtils.setLookAndFeel(PlafUtils.java:298)
	at com.mathworks.fatalexit.FatalExitFrame.doMatlabLikeSetup(FatalExitFrame.java:731)
	at com.mathworks.fatalexit.FatalExitFrame.access$1400(FatalExitFrame.java:93)
	at com.mathworks.fatalexit.FatalExitFrame$13.run(FatalExitFrame.java:882)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:312)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:738)
	at java.awt.EventQueue.access$300(EventQueue.java:103)
	at java.awt.EventQueue$3.run(EventQueue.java:699)
	at java.awt.EventQueue$3.run(EventQueue.java:697)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:708)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
Caused by: java.lang.ClassNotFoundException: com.mathworks.cfbutils.StatEntryReceiver
	at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	... 23 more

------------------------------------------------------------------------
             Bus error detected at Tue Dec 20 17:15:38 2016
------------------------------------------------------------------------

Configuration:
  Crash Decoding      : Disabled - No sandbox or build area path
  Crash Mode          : continue (default)
  Current Graphics Driver: Unknown hardware 
  Current Visual      : Quartz
  Default Encoding    : ISO-8859-1
  Deployed            : false
  Host Name           : h304.aau1x-3.klient.sydhavn2.site.aau.dk
  MATLAB Architecture : maci64
  MATLAB Entitlement ID: 3623390
  MATLAB Root         : /Applications/MATLAB_R2017a.app
  MATLAB Version      : 9.2.0.494151 (R2017a) Prerelease
  OpenGL              : hardware
  Operating System    : Darwin 16.3.0 Darwin Kernel Version 16.3.0: Thu Nov 17 20:23:58 PST 2016; root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64
  Processor ID        : x86 Family 6 Model 70 Stepping 1, GenuineIntel
  Virtual Machine     : Java 1.7.0_75-b13 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
  Window System       : Quartz

Fault Count: 1


Abnormal termination:
Bus error

Register State (from fault):
  RAX = 000070000b884338  RBX = 0000000000000003
  RCX = 0000000000000000  RDX = 000000011f167ac0
  RSP = 00000001167e6dd8  RBP = 000070000b8840f0
  RSI = 0000000107c7be7a  RDI = 000070000b8840c0

   R8 = 00000001167e6e08   R9 = 00007fb229087a00
  R10 = 000070000b8840e0  R11 = 000000010e33ab4a
  R12 = 0000000000000000  R13 = 0000000000000000
  R14 = 00007fb22b4df080  R15 = 000070000b884180

  RIP = 0000000000000000  RFL = 000000010c7a0ea7

   CS = 000070000b884100   FS = 0000000107bb1bdf   GS = 0000000000000000

Stack Trace (from fault):
[  0] 0x00000001079e3714                           bin/maci64/libmwfl.dylib+00034580 _ZN2fl4diag15stacktrace_base7captureERKNS0_14thread_contextEm+00000052
[  1] 0x00000001079e70ca                           bin/maci64/libmwfl.dylib+00049354 _ZN2fl4test17terminate_handledEv+00000810
[  2] 0x00000001079e6b39                           bin/maci64/libmwfl.dylib+00047929 _ZN2fl4diag13terminate_logEPKcPK17__darwin_ucontext+00000185
[  3] 0x000000010ac2d6c1                          bin/maci64/libmwmcr.dylib+00435905 _Z19mnPrintErrorMessageRKNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE+00002081
[  4] 0x000000010ac2d010                          bin/maci64/libmwmcr.dylib+00434192 _Z19mnPrintErrorMessageRKNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE+00000368
[  5] 0x000000010ac2ba0a                          bin/maci64/libmwmcr.dylib+00428554 mnFatalSignalHandler+00000154
[  6] 0x00007fffb4037bba           /usr/lib/system/libsystem_platform.dylib+00011194 _sigtramp+00000026
[  7] 0x0000000000000020                                   <unknown-module>+00000000
[  8] 0x0000000107bb1bdf                             bin/maci64/libmx.dylib+00043999 _ZN6matrix6detail10noninlined12mx_array_api31try_nonrecursive_mxDestroyArrayEP11mxArray_tag+00000015
[  9] 0x000000010e33af8d                     bin/maci64/libmwlxetypes.dylib+00098189 _ZN9MathWorks3lxe6xvalueC1ENSt3__110unique_ptrI11mxArray_tagN6matrix6detail17mxDestroy_deleterEEE+00000077
[ 10] 0x000070000b884230                                   <unknown-module>+00000000
[ 11] 0x000070000b884198                                   <unknown-module>+00000000


If this problem is reproducible, please submit a Service Request via:
    http://www.mathworks.com/support/contact_us/

A technical support engineer might contact you with further information.

Thank you for your help.** This crash report has been saved to disk as /Users/cerkut/matlab_crash_dump.52230-1 **

MATLAB is exiting because of fatal error

M-Shell killed: 9
——	


> On 19 Dec 2016, at 15.02, Eric Ludlam <Eri...@ma...> wrote:
> 
> Hi Rhys,
>  
> I am referring to the C stack size (the amount of memory allocated for both the stack and variables of a running C program.   In this case MATLAB as a subprocess is being limited in how big it’s stack can be because its parent (Emacs) has setup limits for that subprocess.
>  
> This can be a useful thing to do if you don’t always trust a subprocess, since it will prevent the subprocess from accidentally (or perhaps purposefully) locking up your computer by using up all available memory.
>  
> Eric
>  
> From: Rhys Thomas [mailto:e.r...@gm...] 
> Sent: Sunday, December 18, 2016 4:20 AM
> To: mat...@li...
> Subject: Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1
>  
> Hello,
> 
> Is max-lisp-eval-depth what you are looking for?
> 
> max-lisp-eval-depth is a variable defined in ‘C source code’.
> Its value is 800
> 
>   This variable may be risky if used as a file-local variable.
> 
> Documentation:
> Limit on depth in ‘eval’, ‘apply’ and ‘funcall’ before error.
> 
> This limit serves to catch infinite recursions for you before they cause
> actual stack overflow in C, which would be fatal for Emacs.
> You can safely make it considerably larger than its default value,
> if that proves inconveniently small.  However, if you increase it too far,
> Emacs could overflow the real C stack, and crash.
> 
> 
> Regards,
> 
> Rhys
> 
> On 14/12/16 16:46, Eric Ludlam wrote:
> Hello again,
>  
> I’ve been watching progress in development around this Mac/Emacs/MATLAB issue.   They have identified that the reason MATLAB is crashing in Emacs, but not on the command line is because Emacs is setting the stack size.  A way to reproduce outside of Emacs is as follows:
>  
> ulimit -s 8515 
> matlab
>  
> Stacks limited to sizes of 8512 or more works fine for them.
>  
> I looked into stack size within emacs, and saw several references to increasing the stack size to 8519 in Emacs to work around a bug I’m not familiar with, but not to a way to increase the stack size of sub-processes.
>  
> Any Emacs hackers on this list familiar with updating stack size for sub-processes in Emacs as a way to work around this problem?
> Thanks
> Eric
>  
> From: Peter Mao [mailto:pet...@gm...] 
> Sent: Monday, November 14, 2016 11:18 AM
> To: mat...@li...
> Subject: Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1
>  
> Further evidence (I hope this helps someone solve the problem):
> 
> 1. 2016b works in NONE of the emacs terminals: shell, term or e-shell.
> 2. 2016b works fine (even with -nodesktop) from Xquartz's xterm or OSX's terminal
> 3. 2016a works fine in emacs
> 4. Running diff on the java directories (where the potentially offending files reside) shows NO difference between 2016a and 2016b!
>     $ diff -ur /Applications/MATLAB_R2016b.app/sys/java /Applications/MATLAB_R2016a.app/sys/java
> 
> This might not be a Java issue.
>  
> On Thu, Nov 10, 2016 at 7:37 PM, Peter Mao <pet...@gm...> wrote:
> Yes, I'm seeing this problem, too.  Mathworks won't touch it, as it does seem to be a real third party issue with Emacs.
> 
> I'm having the problem with OSX 10.12 and Emacs 25.1.1, although it was also present with my previous emacs (24.5?).
> 
> I checked the environment variables, and the only thing I see significantly different is that emacs shell reports as TERM=dumb, while the Xquartz one is TERM=xterm and apple's terminal is TERM=xterm-256color.
> 
> In all cases, the actual shell is /bin/bash.  I'm guessing this has something to do with how emacs is setting up the shell, but I can't figure out what the issue is, exactly.  May be time to cross post to emacs developers.
> 
> Peter
>  
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Matlab-emacs-discuss mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss
>  
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
> Matlab-emacs-discuss mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Cumhur E. <cum...@gm...> - 2017-03-10 14:28:58

Hi,

I can happily announce that this issue seems to be solved in MATLAB R2017a.

Tried with emacs 25.1 and spacemacs on Mac, and get the long awaited message without crashes 



                            < M A T L A B (R) >
                  Copyright 1984-2017 The MathWorks, Inc.
                   R2017a (9.2.0.538062) 64-bit (maci64)
                             February 23, 2017

 
To get started, type one of these: helpwin, helpdesk, or demo.
For product information, visit www.mathworks.com.
 

>>>

Thanks all for looking into this, best wishes
Cumhur 

> On 20 Dec 2016, at 17.32, Cumhur Erkut <Cum...@gm...> wrote:
> 
> Dear Eric, Rhys, and list
> 
> Thanks so much for looking into this. As Eric predicted, I could not get anything by setting max-lisp-eval-depth to a higher or lower value, matlab still crashes.
> 
> Today I have downloaded the R2017a Prerelease, the behavior is the same but the crash-report is more varied. 
> 
> I have created the following support request at mathworks, I’ll post if I hear something.
> 
> Season’s greetings, Cumhur
> 
> ——	
> Since 2016a, MATLAB crashes in Emacs, in matlab-shell or even without using it from any eshell. The developers of matlab-shell have identified that the reason MATLAB is crashing in Emacs, but not on the command line is because Emacs is setting the stack size. It looks like MATLAB has more demands on stack size since 2016a, and Emacs cannot cope with it. We are trying to find a way to increase the stack-size in Emacs, but if not absolutely needed, could you please also decrease the MATLAB needs? This behavior remains in R2017a Prerelease, would be great to find a solution to keep using Emacs as the main editor of MATLAB code. I attach the crash log below. 
> ---- 
> 
> 
>                            < M A T L A B (R) >
>                  Copyright 1984-2016 The MathWorks, Inc.
>              R2017a Prerelease (9.2.0.494151) 64-bit (maci64)
>                              December 1, 2016
> 
> 
> To get started, type one of these: helpwin, helpdesk, or demo.
> For product information, visit www.mathworks.com.
> 
> Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: com/mathworks/cfbutils/StatEntryReceiver
> 	at com.mathworks.mwswing.MacAppearanceUtils.getMacAlternateSelectedControlColor(MacAppearanceUtils.java:254)
> 	at com.mathworks.mwswing.MacAppearanceUtils.setMacAppearanceColors(MacAppearanceUtils.java:229)
> 	at com.mathworks.mwswing.MacAppearanceUtils.initialize(MacAppearanceUtils.java:41)
> 	at com.mathworks.mwswing.plaf.PlafUtils.correctMacintoshLookAndFeel(PlafUtils.java:203)
> 	at com.mathworks.mwswing.plaf.PlafUtils.correctPlatformLookAndFeel(PlafUtils.java:118)
> 	at com.mathworks.mwswing.plaf.PlafUtils.setLookAndFeel(PlafUtils.java:298)
> 	at com.mathworks.fatalexit.FatalExitFrame.doMatlabLikeSetup(FatalExitFrame.java:731)
> 	at com.mathworks.fatalexit.FatalExitFrame.access$1400(FatalExitFrame.java:93)
> 	at com.mathworks.fatalexit.FatalExitFrame$13.run(FatalExitFrame.java:882)
> 	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:312)
> 	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:738)
> 	at java.awt.EventQueue.access$300(EventQueue.java:103)
> 	at java.awt.EventQueue$3.run(EventQueue.java:699)
> 	at java.awt.EventQueue$3.run(EventQueue.java:697)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
> 	at java.awt.EventQueue.dispatchEvent(EventQueue.java:708)
> 	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
> 	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
> 	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
> 	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
> 	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
> Caused by: java.lang.ClassNotFoundException: com.mathworks.cfbutils.StatEntryReceiver
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> 	... 23 more
> 
> ------------------------------------------------------------------------
>             Bus error detected at Tue Dec 20 17:15:38 2016
> ------------------------------------------------------------------------
> 
> Configuration:
>  Crash Decoding      : Disabled - No sandbox or build area path
>  Crash Mode          : continue (default)
>  Current Graphics Driver: Unknown hardware 
>  Current Visual      : Quartz
>  Default Encoding    : ISO-8859-1
>  Deployed            : false
>  Host Name           : h304.aau1x-3.klient.sydhavn2.site.aau.dk
>  MATLAB Architecture : maci64
>  MATLAB Entitlement ID: 3623390
>  MATLAB Root         : /Applications/MATLAB_R2017a.app
>  MATLAB Version      : 9.2.0.494151 (R2017a) Prerelease
>  OpenGL              : hardware
>  Operating System    : Darwin 16.3.0 Darwin Kernel Version 16.3.0: Thu Nov 17 20:23:58 PST 2016; root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64
>  Processor ID        : x86 Family 6 Model 70 Stepping 1, GenuineIntel
>  Virtual Machine     : Java 1.7.0_75-b13 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
>  Window System       : Quartz
> 
> Fault Count: 1
> 
> 
> Abnormal termination:
> Bus error
> 
> Register State (from fault):
>  RAX = 000070000b884338  RBX = 0000000000000003
>  RCX = 0000000000000000  RDX = 000000011f167ac0
>  RSP = 00000001167e6dd8  RBP = 000070000b8840f0
>  RSI = 0000000107c7be7a  RDI = 000070000b8840c0
> 
>   R8 = 00000001167e6e08   R9 = 00007fb229087a00
>  R10 = 000070000b8840e0  R11 = 000000010e33ab4a
>  R12 = 0000000000000000  R13 = 0000000000000000
>  R14 = 00007fb22b4df080  R15 = 000070000b884180
> 
>  RIP = 0000000000000000  RFL = 000000010c7a0ea7
> 
>   CS = 000070000b884100   FS = 0000000107bb1bdf   GS = 0000000000000000
> 
> Stack Trace (from fault):
> [  0] 0x00000001079e3714                           bin/maci64/libmwfl.dylib+00034580 _ZN2fl4diag15stacktrace_base7captureERKNS0_14thread_contextEm+00000052
> [  1] 0x00000001079e70ca                           bin/maci64/libmwfl.dylib+00049354 _ZN2fl4test17terminate_handledEv+00000810
> [  2] 0x00000001079e6b39                           bin/maci64/libmwfl.dylib+00047929 _ZN2fl4diag13terminate_logEPKcPK17__darwin_ucontext+00000185
> [  3] 0x000000010ac2d6c1                          bin/maci64/libmwmcr.dylib+00435905 _Z19mnPrintErrorMessageRKNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE+00002081
> [  4] 0x000000010ac2d010                          bin/maci64/libmwmcr.dylib+00434192 _Z19mnPrintErrorMessageRKNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE+00000368
> [  5] 0x000000010ac2ba0a                          bin/maci64/libmwmcr.dylib+00428554 mnFatalSignalHandler+00000154
> [  6] 0x00007fffb4037bba           /usr/lib/system/libsystem_platform.dylib+00011194 _sigtramp+00000026
> [  7] 0x0000000000000020                                   <unknown-module>+00000000
> [  8] 0x0000000107bb1bdf                             bin/maci64/libmx.dylib+00043999 _ZN6matrix6detail10noninlined12mx_array_api31try_nonrecursive_mxDestroyArrayEP11mxArray_tag+00000015
> [  9] 0x000000010e33af8d                     bin/maci64/libmwlxetypes.dylib+00098189 _ZN9MathWorks3lxe6xvalueC1ENSt3__110unique_ptrI11mxArray_tagN6matrix6detail17mxDestroy_deleterEEE+00000077
> [ 10] 0x000070000b884230                                   <unknown-module>+00000000
> [ 11] 0x000070000b884198                                   <unknown-module>+00000000
> 
> 
> If this problem is reproducible, please submit a Service Request via:
>    http://www.mathworks.com/support/contact_us/
> 
> A technical support engineer might contact you with further information.
> 
> Thank you for your help.** This crash report has been saved to disk as /Users/cerkut/matlab_crash_dump.52230-1 **
> 
> MATLAB is exiting because of fatal error
> 
> M-Shell killed: 9
> ——	
> 
> 
>> On 19 Dec 2016, at 15.02, Eric Ludlam <Eri...@ma...> wrote:
>> 
>> Hi Rhys,
>> 
>> I am referring to the C stack size (the amount of memory allocated for both the stack and variables of a running C program.   In this case MATLAB as a subprocess is being limited in how big it’s stack can be because its parent (Emacs) has setup limits for that subprocess.
>> 
>> This can be a useful thing to do if you don’t always trust a subprocess, since it will prevent the subprocess from accidentally (or perhaps purposefully) locking up your computer by using up all available memory.
>> 
>> Eric
>> 
>> From: Rhys Thomas [mailto:e.r...@gm...] 
>> Sent: Sunday, December 18, 2016 4:20 AM
>> To: mat...@li...
>> Subject: Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1
>> 
>> Hello,
>> 
>> Is max-lisp-eval-depth what you are looking for?
>> 
>> max-lisp-eval-depth is a variable defined in ‘C source code’.
>> Its value is 800
>> 
>>  This variable may be risky if used as a file-local variable.
>> 
>> Documentation:
>> Limit on depth in ‘eval’, ‘apply’ and ‘funcall’ before error.
>> 
>> This limit serves to catch infinite recursions for you before they cause
>> actual stack overflow in C, which would be fatal for Emacs.
>> You can safely make it considerably larger than its default value,
>> if that proves inconveniently small.  However, if you increase it too far,
>> Emacs could overflow the real C stack, and crash.
>> 
>> 
>> Regards,
>> 
>> Rhys
>> 
>> On 14/12/16 16:46, Eric Ludlam wrote:
>> Hello again,
>> 
>> I’ve been watching progress in development around this Mac/Emacs/MATLAB issue.   They have identified that the reason MATLAB is crashing in Emacs, but not on the command line is because Emacs is setting the stack size.  A way to reproduce outside of Emacs is as follows:
>> 
>> ulimit -s 8515 
>> matlab
>> 
>> Stacks limited to sizes of 8512 or more works fine for them.
>> 
>> I looked into stack size within emacs, and saw several references to increasing the stack size to 8519 in Emacs to work around a bug I’m not familiar with, but not to a way to increase the stack size of sub-processes.
>> 
>> Any Emacs hackers on this list familiar with updating stack size for sub-processes in Emacs as a way to work around this problem?
>> Thanks
>> Eric
>> 
>> From: Peter Mao [mailto:pet...@gm...] 
>> Sent: Monday, November 14, 2016 11:18 AM
>> To: mat...@li...
>> Subject: Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1
>> 
>> Further evidence (I hope this helps someone solve the problem):
>> 
>> 1. 2016b works in NONE of the emacs terminals: shell, term or e-shell.
>> 2. 2016b works fine (even with -nodesktop) from Xquartz's xterm or OSX's terminal
>> 3. 2016a works fine in emacs
>> 4. Running diff on the java directories (where the potentially offending files reside) shows NO difference between 2016a and 2016b!
>>    $ diff -ur /Applications/MATLAB_R2016b.app/sys/java /Applications/MATLAB_R2016a.app/sys/java
>> 
>> This might not be a Java issue.
>> 
>> On Thu, Nov 10, 2016 at 7:37 PM, Peter Mao <pet...@gm...> wrote:
>> Yes, I'm seeing this problem, too.  Mathworks won't touch it, as it does seem to be a real third party issue with Emacs.
>> 
>> I'm having the problem with OSX 10.12 and Emacs 25.1.1, although it was also present with my previous emacs (24.5?).
>> 
>> I checked the environment variables, and the only thing I see significantly different is that emacs shell reports as TERM=dumb, while the Xquartz one is TERM=xterm and apple's terminal is TERM=xterm-256color.
>> 
>> In all cases, the actual shell is /bin/bash.  I'm guessing this has something to do with how emacs is setting up the shell, but I can't figure out what the issue is, exactly.  May be time to cross post to emacs developers.
>> 
>> Peter
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most 
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> 
>> 
>> 
>> _______________________________________________
>> Matlab-emacs-discuss mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most 
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
>> Matlab-emacs-discuss mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss
>

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Deepak C. <dpa...@gm...> - 2016-11-01 15:12:28

I have had no luck.

It seems to have to do with some bug in the JAVA version bundled with
MATLAB. see this StackOverflow answer:
https://stackoverflow.com/questions/18794573/objc10012-class-javalaunchhelper-is-implemented-in-both-libinstrument-dyl

I spent quite some time trying to get MATLAB to work with an updated JDK,
but that just caused other troubles (crashes).

I've gone back to 2016a which works fine.

Deepak


Deepak

On 28 October 2016 at 17:01, Greenwood, Eric (LARC-D314) <
eri...@na...> wrote:

> Hi all,
>
> I’ve been experiencing the same issue with Matlab R2016b on 10.10.  This
> issue occurs when launching R2016b from within any version of Emacs.  As
> Cumhur reported, all previous versions of Matlab seem to work fine.  It
> doesn’t matter how Matlab is launched from within Emacs; as such, this
> isn’t really a matlab-emacs mode issue, but I’m hopeful someone else will
> have found a solution!
>
> Best Regards,
> Eric Greenwood
>
> -----Original Message-----
>
> Hi, thanks for the great matlab emacs, I have been using since R2011a all
> the way to R2016a.
>
>
> I’ve recently updated to Matlab R2016b, and I get a segfault, sometimes
> accompanied with the message below (and sometimes not).
>
> objc[761]: Class JavaLaunchHelper is implemented in both
> /Applications/MATLAB_R2016b.app/sys/java/jre/maci64/jre/bin/java and
> /Applications/MATLAB_R2016b.app/sys/java/jre/maci64/jre/
> lib/jli/libjli.dyli
> b. One of the two will be used. Which one is undefined.
>
> M-Shell segmentation fault: 11
>
> I can launch Matlab R2016b fine from the command line.
>
> Does anybody else get this? Any hints to avoid? ATM, I am keeping both
> R2016a (works with emacs matlab) and (works as a stand alone).
>
> Best wishes — Cumhur
>
> ------------------------------------------------------------
> ------------------
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> _______________________________________________
> Matlab-emacs-discuss mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss
>

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Fritz <fri...@ho...> - 2016-11-01 16:10:15

in the past i had some issues with the matlab bundled java version under debian wheezy, which i solved by using the native java version of my system. the bash script to start matlab was:

#!/bin/bash
export MATLAB_JAVA=/usr/lib/jvm/java-7-openjdk-amd64/jre/
/usr/local/bin/matlab8 $1 $2

On Tue, Nov 1, 2016 at 4:11 PM, Deepak Cherian <dpa...@gm...<mailto:dpa...@gm...>> wrote:
I have had no luck.

It seems to have to do with some bug in the JAVA version bundled with MATLAB. see this StackOverflow answer: https://stackoverflow.com/questions/18794573/objc10012-class-javalaunchhelper-is-implemented-in-both-libinstrument-dyl

I spent quite some time trying to get MATLAB to work with an updated JDK, but that just caused other troubles (crashes).

I've gone back to 2016a which works fine.

Deepak

On 28 October 2016 at 17:01, Greenwood, Eric (LARC-D314) <eri...@na...<mailto:eri...@na...>> wrote:
Hi all,

I’ve been experiencing the same issue with Matlab R2016b on 10.10. This
issue occurs when launching R2016b from within any version of Emacs. As
Cumhur reported, all previous versions of Matlab seem to work fine. It
doesn’t matter how Matlab is launched from within Emacs; as such, this
isn’t really a matlab-emacs mode issue, but I’m hopeful someone else will
have found a solution!

Best Regards,
Eric Greenwood

-----Original Message-----

Hi, thanks for the great matlab emacs, I have been using since R2011a all
the way to R2016a.

I’ve recently updated to Matlab R2016b, and I get a segfault, sometimes
accompanied with the message below (and sometimes not).

objc[761]: Class JavaLaunchHelper is implemented in both
/Applications/MATLAB_R2016b.app/sys/java/jre/maci64/jre/bin/java and
/Applications/MATLAB_R2016b.app/sys/java/jre/maci64/jre/lib/jli/libjli.dyli
b. One of the two will be used. Which one is undefined.

M-Shell segmentation fault: 11

I can launch Matlab R2016b fine from the command line.

Does anybody else get this? Any hints to avoid? ATM, I am keeping both
R2016a (works with emacs matlab) and (works as a stand alone).

Best wishes — Cumhur

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET<http://ASP.NET> CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Matlab-emacs-discuss mailing list
Mat...@li...<mailto:Mat...@li...>
https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Matlab-emacs-discuss mailing list
Mat...@li...<mailto:Mat...@li...>
https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Fritz <fri...@ho...> - 2016-11-01 16:10:16

in the past i had some issues with the matlab bundled java version under debian wheezy, which i solved by using the native java version of my system. the bash script to start matlab was:

#!/bin/bash
export MATLAB_JAVA=/usr/lib/jvm/java-7-openjdk-amd64/jre/
/usr/local/bin/matlab8 $1 $2

On Tue, Nov 1, 2016 at 4:11 PM, Deepak Cherian <dpa...@gm...<mailto:dpa...@gm...>> wrote:
I have had no luck.

I spent quite some time trying to get MATLAB to work with an updated JDK, but that just caused other troubles (crashes).

I've gone back to 2016a which works fine.

Deepak

On 28 October 2016 at 17:01, Greenwood, Eric (LARC-D314) <eri...@na...<mailto:eri...@na...>> wrote:
Hi all,

Best Regards,
Eric Greenwood

-----Original Message-----

Hi, thanks for the great matlab emacs, I have been using since R2011a all
the way to R2016a.

I’ve recently updated to Matlab R2016b, and I get a segfault, sometimes
accompanied with the message below (and sometimes not).

M-Shell segmentation fault: 11

I can launch Matlab R2016b fine from the command line.

Does anybody else get this? Any hints to avoid? ATM, I am keeping both
R2016a (works with emacs matlab) and (works as a stand alone).

Best wishes — Cumhur

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Fritz <fri...@ho...> - 2016-11-01 16:10:22

in the past i had some issues with the matlab bundled java version under debian wheezy, which i solved by using the native java version of my system. the bash script to start matlab was:

#!/bin/bash
export MATLAB_JAVA=/usr/lib/jvm/java-7-openjdk-amd64/jre/
/usr/local/bin/matlab8 $1 $2

On Tue, Nov 1, 2016 at 4:11 PM, Deepak Cherian <dpa...@gm...<mailto:dpa...@gm...>> wrote:
I have had no luck.

I spent quite some time trying to get MATLAB to work with an updated JDK, but that just caused other troubles (crashes).

I've gone back to 2016a which works fine.

Deepak

On 28 October 2016 at 17:01, Greenwood, Eric (LARC-D314) <eri...@na...<mailto:eri...@na...>> wrote:
Hi all,

Best Regards,
Eric Greenwood

-----Original Message-----

Hi, thanks for the great matlab emacs, I have been using since R2011a all
the way to R2016a.

I’ve recently updated to Matlab R2016b, and I get a segfault, sometimes
accompanied with the message below (and sometimes not).

M-Shell segmentation fault: 11

I can launch Matlab R2016b fine from the command line.

Does anybody else get this? Any hints to avoid? ATM, I am keeping both
R2016a (works with emacs matlab) and (works as a stand alone).

Best wishes — Cumhur

Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

From: Greenwood, E. (LARC-D314) <eri...@na...> - 2016-11-03 19:08:29

Attachments: matlab_crash_dump.21866-1

Thanks for the tip. I played around with various settings for the MATLAB_JAVA enviroment variable, including using the SDK, the runtime, and the one included with R2016a.  Unfortunately, MATLAB still fails to launch with an alternative Java, giving the error:

objc[21715]: Class JavaLaunchHelper is implemented in both {$MATLAB_JAVA} and /Applications/MATLAB_R2016b.app/sys/java/jre/maci64/jre/lib/jli/libjli.dylib. One of the two will be used. Which one is undefined.

Interestingly, even running MATLAB under Emacs without Java (e.g. -nojvm or -noawt) still results in a crash calling std::terminate() in my system C++ library. (See crash dump).

I’m out of ideas to resolve this one!


From: Fritz <fri...@ho...<mailto:fri...@ho...>>
Reply-To: Fritz <fri...@ho...<mailto:fri...@ho...>>
Date: Tuesday, November 1, 2016 at 12:10 PM
To: Deepak Cherian <dpa...@gm...<mailto:dpa...@gm...>>
Cc: Eric Greenwood <eri...@na...<mailto:eri...@na...>>, matlab-emacs <mat...@li...<mailto:mat...@li...>>
Subject: Re: [Matlab-emacs-discuss] matlab-shell segfaults with matlab R2016b on Mac OS 10.11.6 Emacs 25.1

in the past i had some issues with the matlab bundled java version under debian wheezy, which i solved by using the native java version of my system. the bash script to start matlab was:

#!/bin/bash
export MATLAB_JAVA=/usr/lib/jvm/java-7-openjdk-amd64/jre/
/usr/local/bin/matlab8 $1 $2



On Tue, Nov 1, 2016 at 4:11 PM, Deepak Cherian <dpa...@gm...<mailto:dpa...@gm...>> wrote:
I have had no luck.

It seems to have to do with some bug in the JAVA version bundled with MATLAB. see this StackOverflow answer: https://stackoverflow.com/questions/18794573/objc10012-class-javalaunchhelper-is-implemented-in-both-libinstrument-dyl

I spent quite some time trying to get MATLAB to work with an updated JDK, but that just caused other troubles (crashes).

I've gone back to 2016a which works fine.

Deepak


Deepak

On 28 October 2016 at 17:01, Greenwood, Eric (LARC-D314) <eri...@na...<mailto:eri...@na...>> wrote:
Hi all,

I’ve been experiencing the same issue with Matlab R2016b on 10.10.  This
issue occurs when launching R2016b from within any version of Emacs.  As
Cumhur reported, all previous versions of Matlab seem to work fine.  It
doesn’t matter how Matlab is launched from within Emacs; as such, this
isn’t really a matlab-emacs mode issue, but I’m hopeful someone else will
have found a solution!

Best Regards,
Eric Greenwood

-----Original Message-----

Hi, thanks for the great matlab emacs, I have been using since R2011a all
the way to R2016a.


I’ve recently updated to Matlab R2016b, and I get a segfault, sometimes
accompanied with the message below (and sometimes not).

objc[761]: Class JavaLaunchHelper is implemented in both
/Applications/MATLAB_R2016b.app/sys/java/jre/maci64/jre/bin/java and
/Applications/MATLAB_R2016b.app/sys/java/jre/maci64/jre/lib/jli/libjli.dyli
b. One of the two will be used. Which one is undefined.

M-Shell segmentation fault: 11

I can launch Matlab R2016b fine from the command line.

Does anybody else get this? Any hints to avoid? ATM, I am keeping both
R2016a (works with emacs matlab) and (works as a stand alone).

Best wishes — Cumhur

------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET<http://ASP.NET> CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Matlab-emacs-discuss mailing list
Mat...@li...<mailto:Mat...@li...>
https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Matlab-emacs-discuss mailing list
Mat...@li...<mailto:Mat...@li...>
https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss