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 <cumhur.er...@gmail.com> 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 <eric.lud...@mathworks.com> 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.rhys.tho...@gmail.com]
>> Sent: Sunday, December 18, 2016 4:20 AM
>> To: matlab-emacs-discuss@lists.sourceforge.net
>> 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:peter....@gmail.com]
>> Sent: Monday, November 14, 2016 11:18 AM
>> To: matlab-emacs-discuss@lists.sourceforge.net
>> 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 <peter....@gmail.com> 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
>> Matlab-emacs-discuss@lists.sourceforge.net
>> 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
>> Matlab-emacs-discuss@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss
>
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Matlab-emacs-discuss mailing list
Matlab-emacs-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matlab-emacs-discuss
