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 <[email protected]> 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:[email protected]]
> Sent: Sunday, December 18, 2016 4:20 AM
> To: [email protected]
> 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:[email protected]]
> Sent: Monday, November 14, 2016 11:18 AM
> To: [email protected]
> 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 <[email protected]> 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
> [email protected]
> 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
> [email protected]
> 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/intel
_______________________________________________
Matlab-emacs-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss
