Cycling 74 » Topic: Crash Report: call outlet() with an invalid outlet index

Crash Report: call outlet() with an invalid outlet index

Adam Murray — Tue, 12 Feb 2008 06:56:51 +0000

I know it should be the responsibility of my Max object to check outlet indexes, but I just got burned by this *again* so here we go…

Steps to Reproduce:

1. Build this MXJ max object:
import com.cycling74.max.MaxObject;
public class crash extends MaxObject {
public void bang() {
outlet(2, “goodbye”);
}
}

2. Create this patch:
#P button 93 63 15 0;
#P newex 93 88 56 196617 mxj crash;
#P connect 1 0 0 0;

3. Click the button. Max crashes.

Expected behavior:
Do not crash! Print an error to the Max window indicating an invalid outlet index was used.

Crash Log:

Process: MaxMSP [338]
Path: /Applications/MaxMSP 4.6/MaxMSP.app/Contents/MacOS/MaxMSP
Identifier: com.cycling74.MaxMSP46
Version: ??? (4.6.3)
Code Type: X86 (Native)
Parent Process: launchd [74]

Date/Time: 2008-02-11 22:52:52.218 -0800
OS Version: Mac OS X 10.5.1 (9B21)
Report Version: 6

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000050dd9a05
Crashed Thread: 0

Application Specific Information:

Java information:
Version: Java HotSpot(TM) Client VM (1.5.0_13-119 mixed mode)
Virtual Machine version: Java HotSpot(TM) Client VM (1.5.0_13-119) for macosx-x86, built on Sep 28 2007 23:59:21 by root with gcc 4.0.1 (Apple Inc. build 5465)
Exception type: Bus Error (0xa) at pc=0x0002ff41

Current thread (0x17f014d0): JavaThread “AWT-AppKit” [_thread_in_native, id=-1602322592]
Stack: [0xbf800000,0xc0000000)
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.cycling74.max.MaxObject.doOutlet(ILjava/lang/String;[Lcom/cycling74/max/Atom;)Z+0
j com.cycling74.max.MaxObject.outlet(ILjava/lang/String;[Lcom/cycling74/max/Atom;)Z+49
j com.cycling74.max.MaxObject.outlet(ILjava/lang/String;)Z+6
j crash.bang()V+4
v ~StubRoutines::call_stub
Java Threads: ( => current thread )
0x17f0ebb0 JavaThread "AWT-Shutdown" [_thread_blocked, id=17867264]
0x17f0b8b0 JavaThread “Low Memory Detector” daemon [_thread_blocked, id=17573888]
0x17f0ae80 JavaThread “CompilerThread0″ daemon [_thread_blocked, id=17570304]
0x17f0a930 JavaThread “Signal Dispatcher” daemon [_thread_blocked, id=17566720]
0x17f0a670 JavaThread “Surrogate Locker Thread (CMS)” daemon [_thread_blocked, id=17560064]
0x17f09d80 JavaThread “Finalizer” daemon [_thread_blocked, id=17556480]
0x17f09980 JavaThread “Reference Handler” daemon [_thread_blocked, id=17550336]
=>0x17f014d0 JavaThread “AWT-AppKit” [_thread_in_native, id=-1602322592]
Other Threads:
0x17f090d0 VMThread [id=17476608]
0x17f0c550 WatcherThread [id=17577472]

VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None

Heap
par new generation total 4032K, used 1134K [0x1c3e0000, 0x1c7e0000, 0x1cbe0000)
eden space 3968K, 28% used [0x1c3e0000, 0x1c4fbac0, 0x1c7c0000)
from space 64K, 0% used [0x1c7c0000, 0x1c7c0000, 0x1c7d0000)
to space 64K, 0% used [0x1c7d0000, 0x1c7d0000, 0x1c7e0000)
concurrent mark-sweep generation total 61440K, used 0K [0x1cbe0000, 0x207e0000, 0x2c3e0000)
concurrent-mark-sweep perm gen total 8192K, used 2772K [0x2c3e0000, 0x2cbe0000, 0x303e0000)

Virtual Machine arguments:
JVM args: -Xincgc -Xms64m -Xmx256m
Java command:
launcher type: generic

Thread 0 Crashed:
0 com.cycling74.MaxMSP46 0x0002ff41 typedmess_lookup + 9 (message.c:405)
1 com.cycling74.MaxMSP46 0x000e854f outlet_anything + 301 (inletoutlet.c:968)
2 com.cycling74.MaxAPI 0x00e665b9 outlet_anything + 59
3 com.cycling74.mxj 0x1797b16e mxj_outlet_anything + 139
4 ??? 0x1a3679b1 0 + 439777713
5 ??? 0x1a361b2b 0 + 439753515
6 ??? 0x1a361b2b 0 + 439753515
7 ??? 0x1a361b2b 0 + 439753515
8 ??? 0x1a35f227 0 + 439743015
9 libjvm.dylib 0x17b9e63a 0x17a85000 + 1152570
10 libjvm.dylib 0x17b9e356 0x17a85000 + 1151830
11 libjvm.dylib 0x17b2868c 0x17a85000 + 669324
12 libjvm.dylib 0x17c954fa JNI_CreateJavaVM_Impl + 106170
13 com.cycling74.mxj 0x1796eb22 maxjava_bang + 73
14 com.cycling74.MaxMSP46 0x000e7af3 outlet_bang + 283 (inletoutlet.c:657)
15 com.cycling74.MaxMSP46 0x00075eb5 vbutton_click(vbutton*, Point) + 35 (button.c:179)
16 com.cycling74.MaxMSP46 0x0000fbe8 box_click + 148 (box.c:123)
17 com.cycling74.MaxMSP46 0x000363b4 patcher_boxclick + 436 (patcher.c:2175)
18 com.cycling74.MaxMSP46 0x000382a1 patcher_click + 1195 (patcher.c:2424)
19 com.cycling74.MaxMSP46 0x0006a7c5 wind_click + 143 (window.c:1118)
20 com.cycling74.MaxMSP46 0x0006f880 wind_event + 394 (window.c:818)
21 com.cycling74.MaxMSP46 0x0002807d app_eventhandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 1273 (main.c:1658)
22 com.apple.HIToolbox 0x95a0e863 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1181
23 com.apple.HIToolbox 0x95a0dc9d SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 405
24 com.apple.HIToolbox 0x95a2a08e SendEventToEventTarget + 52
25 com.apple.HIToolbox 0x95a3cb73 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 1211
26 com.apple.HIToolbox 0x95a0ec1c DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 2134
27 com.apple.HIToolbox 0x95a0dc9d SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 405
28 com.apple.HIToolbox 0x95a2a08e SendEventToEventTarget + 52
29 com.apple.HIToolbox 0x95a97444 ToolboxEventDispatcher + 86
30 com.apple.HIToolbox 0x95a93c9e RunApplicationEventLoop + 222
31 com.cycling74.MaxMSP46 0x00027854 app_run + 52 (main.c:1519)
32 com.cycling74.MaxMSP46 0x00027afe main + 680 (main.c:416)
33 com.cycling74.MaxMSP46 0x00002ba2 _start + 216
34 com.cycling74.MaxMSP46 0x00002ac9 start + 41

[other threads omitted]

Re: Crash Report: call outlet() with an invalid outlet index

topher lafata — Wed, 13 Feb 2008 17:01:52 +0000

The thinking with this is that checking automatically if your outlet
index is in range everytime adds overhead to the outlet call.
If you wanted to subclass MaxObject with outletSafe it would be
pretty trivial. We don’t want to force the checking on someone
who may not want it to happen every outlet call.
t

On Feb 11, 2008, at 22:56 PM, Adam Murray wrote:

>
> I know it should be the responsibility of my Max object to check
> outlet indexes, but I just got burned by this *again* so here we go…
>
>
> Steps to Reproduce:
>
> 1. Build this MXJ max object:
> import com.cycling74.max.MaxObject;
> public class crash extends MaxObject {
> public void bang() {
> outlet(2, “goodbye”);
> }
> }
>
> 2. Create this patch:
> #P button 93 63 15 0;
> #P newex 93 88 56 196617 mxj crash;
> #P connect 1 0 0 0;
>
> 3. Click the button. Max crashes.
>
>
> Expected behavior:
> Do not crash! Print an error to the Max window indicating an
> invalid outlet index was used.
>
>
> Crash Log:
>
> Process: MaxMSP [338]
> Path: /Applications/MaxMSP 4.6/MaxMSP.app/Contents/MacOS/
> MaxMSP
> Identifier: com.cycling74.MaxMSP46
> Version: ??? (4.6.3)
> Code Type: X86 (Native)
> Parent Process: launchd [74]
>
> Date/Time: 2008-02-11 22:52:52.218 -0800
> OS Version: Mac OS X 10.5.1 (9B21)
> Report Version: 6
>
> Exception Type: EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes: KERN_INVALID_ADDRESS at 0x0000000050dd9a05
> Crashed Thread: 0
>
> Application Specific Information:
>
> Java information:
> Version: Java HotSpot(TM) Client VM (1.5.0_13-119 mixed mode)
> Virtual Machine version: Java HotSpot(TM) Client VM (1.5.0_13-119)
> for macosx-x86, built on Sep 28 2007 23:59:21 by root with gcc
> 4.0.1 (Apple Inc. build 5465)
> Exception type: Bus Error (0xa) at pc=0x0002ff41
>
> Current thread (0x17f014d0): JavaThread “AWT-
> AppKit” [_thread_in_native, id=-1602322592]
> Stack: [0xbf800000,0xc0000000)
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j com.cycling74.max.MaxObject.doOutlet(ILjava/lang/String;[Lcom/
> cycling74/max/Atom;)Z+0
> j com.cycling74.max.MaxObject.outlet(ILjava/lang/String;[Lcom/
> cycling74/max/Atom;)Z+49
> j com.cycling74.max.MaxObject.outlet(ILjava/lang/String;)Z+6
> j crash.bang()V+4
> v ~StubRoutines::call_stub
> Java Threads: ( => current thread )
> 0x17f0ebb0 JavaThread "AWT-Shutdown" [_thread_blocked, id=17867264]
> 0x17f0b8b0 JavaThread “Low Memory Detector” daemon
> [_thread_blocked, id=17573888]
> 0x17f0ae80 JavaThread “CompilerThread0″ daemon [_thread_blocked,
> id=17570304]
> 0x17f0a930 JavaThread “Signal Dispatcher” daemon
> [_thread_blocked, id=17566720]
> 0x17f0a670 JavaThread “Surrogate Locker Thread (CMS)” daemon
> [_thread_blocked, id=17560064]
> 0x17f09d80 JavaThread “Finalizer” daemon [_thread_blocked,
> id=17556480]
> 0x17f09980 JavaThread “Reference Handler” daemon
> [_thread_blocked, id=17550336]
> =>0x17f014d0 JavaThread “AWT-AppKit” [_thread_in_native,
> id=-1602322592]
> Other Threads:
> 0x17f090d0 VMThread [id=17476608]
> 0x17f0c550 WatcherThread [id=17577472]
>
> VM state:not at safepoint (normal execution)
> VM Mutex/Monitor currently owned by a thread: None
>
> Heap
> par new generation total 4032K, used 1134K [0x1c3e0000,
> 0x1c7e0000, 0x1cbe0000)
> eden space 3968K, 28% used [0x1c3e0000, 0x1c4fbac0, 0x1c7c0000)
> from space 64K, 0% used [0x1c7c0000, 0x1c7c0000, 0x1c7d0000)
> to space 64K, 0% used [0x1c7d0000, 0x1c7d0000, 0x1c7e0000)
> concurrent mark-sweep generation total 61440K, used 0K
> [0x1cbe0000, 0x207e0000, 0x2c3e0000)
> concurrent-mark-sweep perm gen total 8192K, used 2772K
> [0x2c3e0000, 0x2cbe0000, 0x303e0000)
>
> Virtual Machine arguments:
> JVM args: -Xincgc -Xms64m -Xmx256m
> Java command:
> launcher type: generic
>
> Thread 0 Crashed:
> 0 com.cycling74.MaxMSP46 0x0002ff41 typedmess_lookup + 9
> (message.c:405)
> 1 com.cycling74.MaxMSP46 0x000e854f outlet_anything + 301
> (inletoutlet.c:968)
> 2 com.cycling74.MaxAPI 0x00e665b9 outlet_anything + 59
> 3 com.cycling74.mxj 0x1797b16e mxj_outlet_anything +
> 139
> 4 ??? 0x1a3679b1 0 + 439777713
> 5 ??? 0x1a361b2b 0 + 439753515
> 6 ??? 0x1a361b2b 0 + 439753515
> 7 ??? 0x1a361b2b 0 + 439753515
> 8 ??? 0x1a35f227 0 + 439743015
> 9 libjvm.dylib 0x17b9e63a 0x17a85000 + 1152570
> 10 libjvm.dylib 0x17b9e356 0x17a85000 + 1151830
> 11 libjvm.dylib 0x17b2868c 0x17a85000 + 669324
> 12 libjvm.dylib 0x17c954fa JNI_CreateJavaVM_Impl
> + 106170
> 13 com.cycling74.mxj 0x1796eb22 maxjava_bang + 73
> 14 com.cycling74.MaxMSP46 0x000e7af3 outlet_bang + 283
> (inletoutlet.c:657)
> 15 com.cycling74.MaxMSP46 0x00075eb5 vbutton_click
> (vbutton*, Point) + 35 (button.c:179)
> 16 com.cycling74.MaxMSP46 0x0000fbe8 box_click + 148
> (box.c:123)
> 17 com.cycling74.MaxMSP46 0x000363b4 patcher_boxclick +
> 436 (patcher.c:2175)
> 18 com.cycling74.MaxMSP46 0x000382a1 patcher_click + 1195
> (patcher.c:2424)
> 19 com.cycling74.MaxMSP46 0x0006a7c5 wind_click + 143
> (window.c:1118)
> 20 com.cycling74.MaxMSP46 0x0006f880 wind_event + 394
> (window.c:818)
> 21 com.cycling74.MaxMSP46 0x0002807d app_eventhandler
> (OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 1273 (main.c:
> 1658)
> 22 com.apple.HIToolbox 0x95a0e863
> DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,
> HandlerCallRec*) + 1181
> 23 com.apple.HIToolbox 0x95a0dc9d
> SendEventToEventTargetInternal(OpaqueEventRef*,
> OpaqueEventTargetRef*, HandlerCallRec*) + 405
> 24 com.apple.HIToolbox 0x95a2a08e
> SendEventToEventTarget + 52
> 25 com.apple.HIToolbox 0x95a3cb73
> ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*,
> OpaqueEventRef*, void*) + 1211
> 26 com.apple.HIToolbox 0x95a0ec1c
> DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,
> HandlerCallRec*) + 2134
> 27 com.apple.HIToolbox 0x95a0dc9d
> SendEventToEventTargetInternal(OpaqueEventRef*,
> OpaqueEventTargetRef*, HandlerCallRec*) + 405
> 28 com.apple.HIToolbox 0x95a2a08e
> SendEventToEventTarget + 52
> 29 com.apple.HIToolbox 0x95a97444
> ToolboxEventDispatcher + 86
> 30 com.apple.HIToolbox 0x95a93c9e
> RunApplicationEventLoop + 222
> 31 com.cycling74.MaxMSP46 0x00027854 app_run + 52 (main.c:
> 1519)
> 32 com.cycling74.MaxMSP46 0x00027afe main + 680 (main.c:416)
> 33 com.cycling74.MaxMSP46 0x00002ba2 _start + 216
> 34 com.cycling74.MaxMSP46 0x00002ac9 start + 41
>
> [other threads omitted]
> –
> Adam Murray
> compusition.com

Re: Crash Report: call outlet() with an invalid outlet index

Adam Murray — Wed, 13 Feb 2008 17:20:16 +0000

Quote: topher lafata wrote on Wed, 13 February 2008 09:01
—————————————————-
> The thinking with this is that checking automatically if your outlet
> index is in range everytime adds overhead to the outlet call.
> If you wanted to subclass MaxObject with outletSafe it would be
> pretty trivial. We don’t want to force the checking on someone
> who may not want it to happen every outlet call.
> t
>

I figured as much, and that definitely makes sense. Still, I wish there was a way it could bail on the current operation and not crash the whole Max application. At least the outletSafe() approach is indeed trivial to add when I need it.

Re: Crash Report: call outlet() with an invalid outlet index

Peter Castine — Thu, 14 Feb 2008 10:33:08 +0000

Quote: topher lafata wrote on Wed, 13 February 2008 18:01
—————————————————-
> The thinking with this is that checking automatically if your outlet
> index is in range everytime adds overhead to the outlet call.
> If you wanted to subclass MaxObject with outletSafe it would be
> pretty trivial. We don’t want to force the checking on someone
> who may not want it to happen every outlet call.
—————————————————-

It’s probably far too late to change the implementation… but it seems that in the Java mindset, it would be more idiomatic to have checking the default behavior (as is the case with arrays and everything else I can think of), and either a flag or a subclass to turn range&null checking off if the performance hit makes a difference.

It’s exceptional for an object to have a reason to speak to a null outlet, but seems it can happen. When programming C we’re used to the fact that any mishap can crash Max and program carefully (for the most part). Java gives you this feeling of comfort that no matter how stupidly you code, Everything Will Be All Right…

I’ll read the moral of Adam’s story to be that no programming language is really safe. Hang that in next to “Slow but steady wins the race” and “Look before you leap.”

– P.

Re: Crash Report: call outlet() with an invalid outlet index

Adam Murray — Thu, 14 Feb 2008 17:39:02 +0000

Quote: Peter Castine wrote on Thu, 14 February 2008 02:33
—————————————————-
>
> It’s probably far too late to change the implementation… but it seems that in the Java mindset, it would be more idiomatic to have checking the default behavior

Yes, exactly. Crashing Max because of a bad outlet reference is caused by accessing an invalid location in memory. Java manages memory for you, so you get used to the idea that things like this won’t happen. But since MXJ calls into the underlying Max C implementation, of course this kind of crash is possible.

>
> It’s exceptional for an object to have a reason to speak to a null outlet, but seems it can happen. … Java gives you this feeling of comfort that no matter how stupidly you code, Everything Will Be All Right…

Well I have had my share of stupid coding moments, but to put this in perspective: I was running into this problem with my ruby object, because I have no control over what scripts the user will try to evaluate. It is entirely possible, and very easy, to reference a null outlet from a script and instantly crash Max. So I had to jump through some extra hoops to make sure this can’t happen. Now I’m a little wiser :)

Re: Crash Report: call outlet() with an invalid outlet index

Joshua Kit Clayton — Thu, 14 Feb 2008 18:02:34 +0000

The cost of a size comparison and branching should be close to zero
as compared to the Java->Context switcth, so I think that this is
worth fixing (Max 5). However, that wont help you for now.

-Joshua

Re: Crash Report: call outlet() with an invalid outlet index

Adam Murray — Thu, 14 Feb 2008 18:47:25 +0000

Quote: jkc wrote on Thu, 14 February 2008 10:02
—————————————————-
>
> The cost of a size comparison and branching should be close to zero
> as compared to the Java->Context switcth, so I think that this is
> worth fixing (Max 5).

I was wondering about that when Topher brought up the issue of overhead. Great to hear!

Re: Crash Report: call outlet() with an invalid outlet index

topher lafata — Fri, 15 Feb 2008 07:08:49 +0000

yes. perhaps the original decision to optimize for this sort of thing
was premature given how things actually ended up playing out with the
JNI context switch.
sorry you suffered as a result adam.
t

On Feb 14, 2008, at 10:47 AM, Adam Murray wrote:

>
> Quote: jkc wrote on Thu, 14 February 2008 10:02
> —————————————————-
>>
>> The cost of a size comparison and branching should be close to zero
>> as compared to the Java->Context switcth, so I think that this is
>> worth fixing (Max 5).
>
> I was wondering about that when Topher brought up the issue of
> overhead. Great to hear!
>
>
> –
> Adam Murray
> compusition.com

Re: Crash Report: call outlet() with an invalid outlet index

Adam Murray — Sat, 27 Sep 2008 06:01:09 +0000

This behavior still exists in Max 5.0.4. I imagine this is a very easy fix, and avoiding crashes when possible is important, right? Probably the Java SDK is not getting much love these days. I’m sure Max 5 C SDK and Pluggo is a priority. Maybe one day soon, though?

Re: Crash Report: call outlet() with an invalid outlet index

Emmanuel Jourdan — Sat, 27 Sep 2008 10:03:06 +0000

On 27 sept. 08, at 08:01, Adam Murray wrote:

> This behavior still exists in Max 5.0.4. I imagine this is a very
> easy fix, and avoiding crashes when possible is important, right?
> Probably the Java SDK is not getting much love these days. I’m sure
> Max 5 C SDK and Pluggo is a priority. Maybe one day soon, though?

Thanks for your insistance. This is fixed for the next incremental. It
will post an error in the Max window, and stop crashing ;-)

Re: Crash Report: call outlet() with an invalid outlet index

nick rothwell / cassiel — Sat, 27 Sep 2008 11:19:19 +0000

Talking of insistence: I mentioned a while ago that MaxObject has far
fewer outletHigh() overloads than outlet() ones. Is this intentional?

– N.

Nick Rothwell / Cassiel.com Limited
http://www.cassiel.com
http://www.myspace.com/cassieldotcom
http://www.last.fm/music/cassiel
http://www.reverbnation.com/cassiel
http://www.linkedin.com/in/cassiel
http://www.loadbang.net

Re: Crash Report: call outlet() with an invalid outlet index

Adam Murray — Thu, 02 Oct 2008 02:05:35 +0000

Quote: Emmanuel Jourdan wrote on Sat, 27 September 2008 03:03
—————————————————-
>
> Thanks for your insistance. This is fixed for the next incremental. It
> will post an error in the Max window, and stop crashing ;-)
>

Just tried out the new release. Thank you!! This fix will make my life easier.

My ajm.ruby object can no longer bring down Max because a script accesses a bad outlet. I had sort of addressed that problem before but I’m introducing some new features that make it really easy to crash Max that way due to a simple typo. Now I don’t have to worry about it. Awesome.