Jennek Geels

I have been toying with Jitter Tutorial example 47.

Most of the times when I reload/recompile the javascript file, max 

With other patches including javascript I did not experience this.

There i could edit and recompile with the patch open and even when 

I have tried to isolate the problem and I am led to believe that it is

the JitterListener that is causing the crash.

If I remove the JitterListener, there are no crashes.

The interesting thing is that the crash does not happen on the first 

this happens with the internal js editor as well as with textwrangler 

close and reopen patch after every save of the js file.

open js file by double clicking the js object.

var mylistener = new JitterListener(mywindow.getregisteredname(), 

Path: /Applications/MaxMSP 4.6/MaxMSP.app/Contents/MacOS/MaxMSP

Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000058

0 com.cycling74.MaxJSRef     0x315b4175 js_GetSlotThreadSafe + 54

1 com.cycling74.MaxJSRef     0x315b2ec0 js_Invoke + 554

2 com.cycling74.MaxJSRef     0x315b35cb js_InternalInvoke + 178

3 com.cycling74.MaxJSRef     0x3158694f JS_CallFunction + 64

4 com.cycling74.jsjitter     0x31606844 

jsjitterlistener_callback + 787 (bundle1.s:110)

5 com.cycling74.JitterAPI     0x163e66aa jit_listener_notify + 604

6 com.cycling74.MaxMSP46     0x0011d2d7 object_method + 1431 

7 com.cycling74.MaxMSP46     0x000df7a3 linklist_methodall + 

8 com.cycling74.MaxMSP46     0x0011cafd object_notify + 109 

9 com.cycling74.MaxMSP46     0x0011d48f object_attr_setvalueof 

10 com.cycling74.MaxAPI     0x019e2149 object_attr_setvalueof 

11 com.cycling74.jsjitter     0x31607dbd 

jsjitterwrap_SetProperty + 204 (bundle1.s:110)

12 com.cycling74.MaxJSRef     0x315ceb97 js_SetProperty + 1410

13 com.cycling74.MaxJSRef     0x315af3ce js_Interpret + 25730

14 com.cycling74.MaxJSRef     0x315b2c30 js_Execute + 477

15 com.cycling74.MaxJSRef     0x315867e9 JS_ExecuteScript + 55

16 com.cycling74.js     0x3173fbb1 js_eval + 816 

17 com.cycling74.js     0x3173fc4e js_compile + 62 

18 com.cycling74.js     0x3173fce6 js_filechanged + 130 

19 com.cycling74.MaxMSP46     0x00114a00 filewatcher_check 

(_filewatcher*) + 148 (filewatcher.c:144)

20 com.cycling74.MaxMSP46     0x000584b3 sched_dequeue + 129 

21 com.cycling74.MaxMSP46     0x00025cdd max_doeventtimerproc + 

22 com.cycling74.MaxMSP46     0x00025d9b max_eventtimerproc + 

23 com.apple.HIToolbox     0x92f3a8c2 TimerVector + 31

24 com.apple.CoreFoundation     0x90823bc9 CFRunLoopRunSpecific + 

25 com.apple.CoreFoundation     0x90822eb5 CFRunLoopRunInMode + 61

26 com.apple.HIToolbox     0x92f02b90 

27 com.apple.HIToolbox     0x92f02297 ReceiveNextEventCommon 

28 com.apple.HIToolbox     0x92f4a929 _AcquireNextEvent + 58

29 com.apple.HIToolbox     0x92f4a774 

30 com.cycling74.MaxMSP46     0x0002683a app_run + 52 (main.c: 

I have been toying with Jitter Tutorial example 47.
Most of the times when I reload/recompile the javascript file, max  
crashes.
Even when the metro is off.

With other patches including javascript I did not experience this.
There i could edit and recompile with the patch open and even when  
running.
very helpful when exploring.

I have tried to isolate the problem and I am led to believe that it is
the JitterListener that is causing the crash.
If I remove the JitterListener, there are no crashes.

The interesting thing is that the crash does not happen on the first  
recompile,
but always on the second.

this happens with the internal js editor as well as with textwrangler  
as the external editor.

current workaround:
close and reopen patch after every save of the js file.

find below the details.
-jennek
=========

steps to reproduce:
open 47jJitterListener.pat
open js file by double clicking the js object.
insert a post statement in function bang
save file
turn metro on
observe posts are in effect
turn metro off
insert another post in function bang
save file
max crashes

as a reference try this:
close patch
comment out the line
var mylistener = new JitterListener(mywindow.getregisteredname(),  
thecallback);
in another text editor
reopen patch
edit js file as much as you like.
no crashes like before.

Partial crash log appended.
This is on MacBookPro 10.4.7
max 4.6/jitter1.6

Date/Time:      2006-08-27 02:20:42.361 +0000
OS Version:     10.4.7 (Build 8J2135a)
Report Version: 4

Command: MaxMSP
Path:    /Applications/MaxMSP 4.6/MaxMSP.app/Contents/MacOS/MaxMSP
Parent:  WindowServer [59]

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000058

Thread 0 Crashed:
0   com.cycling74.MaxJSRef         	0x315b4175 js_GetSlotThreadSafe + 54
1   com.cycling74.MaxJSRef         	0x315b2ec0 js_Invoke + 554
2   com.cycling74.MaxJSRef         	0x315b35cb js_InternalInvoke + 178
3   com.cycling74.MaxJSRef         	0x3158694f JS_CallFunction + 64
4   com.cycling74.jsjitter         	0x31606844  
jsjitterlistener_callback + 787 (bundle1.s:110)
5   com.cycling74.JitterAPI        	0x163e66aa jit_listener_notify + 604
6   com.cycling74.MaxMSP46         	0x0011d2d7 object_method + 1431  
(obex.c:798)
7   com.cycling74.MaxMSP46         	0x000df7a3 linklist_methodall +  
217 (linklist.c:887)
8   com.cycling74.MaxMSP46         	0x0011cafd object_notify + 109  
(obex.c:1581)
9   com.cycling74.MaxMSP46         	0x0011d48f object_attr_setvalueof  
+ 285 (obex.c:1183)
10  com.cycling74.MaxAPI           	0x019e2149 object_attr_setvalueof  
+ 51
11  com.cycling74.jsjitter         	0x31607dbd  
jsjitterwrap_SetProperty + 204 (bundle1.s:110)
12  com.cycling74.MaxJSRef         	0x315ceb97 js_SetProperty + 1410
13  com.cycling74.MaxJSRef         	0x315af3ce js_Interpret + 25730
14  com.cycling74.MaxJSRef         	0x315b2c30 js_Execute + 477
15  com.cycling74.MaxJSRef         	0x315867e9 JS_ExecuteScript + 55
16  com.cycling74.js               	0x3173fbb1 js_eval + 816  
(bundle1.s:110)
17  com.cycling74.js               	0x3173fc4e js_compile + 62  
(bundle1.s:110)
18  com.cycling74.js               	0x3173fce6 js_filechanged + 130  
(bundle1.s:110)
19  com.cycling74.MaxMSP46         	0x00114a00 filewatcher_check 
(_filewatcher*) + 148 (filewatcher.c:144)
20  com.cycling74.MaxMSP46         	0x000584b3 sched_dequeue + 129  
(sched.c:351)
21  com.cycling74.MaxMSP46         	0x00025cdd max_doeventtimerproc +  
101 (main.c:645)
22  com.cycling74.MaxMSP46         	0x00025d9b max_eventtimerproc +  
35 (main.c:691)
23  com.apple.HIToolbox            	0x92f3a8c2 TimerVector + 31
24  com.apple.CoreFoundation       	0x90823bc9 CFRunLoopRunSpecific +  
3341
25  com.apple.CoreFoundation       	0x90822eb5 CFRunLoopRunInMode + 61
26  com.apple.HIToolbox            	0x92f02b90  
RunCurrentEventLoopInMode + 285
27  com.apple.HIToolbox            	0x92f02297 ReceiveNextEventCommon  
+ 385
28  com.apple.HIToolbox            	0x92f4a929 _AcquireNextEvent + 58
29  com.apple.HIToolbox            	0x92f4a774  
RunApplicationEventLoop + 150
30  com.cycling74.MaxMSP46         	0x0002683a app_run + 52 (main.c: 
1458)
31  com.cycling74.MaxMSP46         	0x00026ae4 main + 680 (main.c:415)
32  com.cycling74.MaxMSP46         	0x00001de2 _start + 228 (crt.c:272)
33  com.cycling74.MaxMSP46         	0x00001cfd start + 41

recompiling-with-jitterlistener-leads-to-crash

I posted the problem report below a week ago, but I have had no 

Is there anybody out there willing to confirm or contradict my findings?

is it just me (or my configuration) and can it be mended?

it is getting very annoying to develop with JitterListener

On 27-aug-2006, at 2:41, jennek geels wrote:

> I have been toying with Jitter Tutorial example 47.

> Most of the times when I reload/recompile the javascript file, max 

> With other patches including javascript I did not experience this.

> There i could edit and recompile with the patch open and even when 

> I have tried to isolate the problem and I am led to believe that it is

> the JitterListener that is causing the crash.

> If I remove the JitterListener, there are no crashes.

> The interesting thing is that the crash does not happen on the 

> this happens with the internal js editor as well as with 

> close and reopen patch after every save of the js file.

> open js file by double clicking the js object.

> insert a post statement in function bang

> var mylistener = new JitterListener(mywindow.getregisteredname(), 

hi,
I posted the problem report below a week ago, but I have had no  
reaction.
Is there anybody out there willing to confirm or contradict my findings?
is it just me (or my configuration) and can it be mended?
it is getting very annoying to develop with JitterListener
thanks
-jennek

> Hi,
>
> I have been toying with Jitter Tutorial example 47.
> Most of the times when I reload/recompile the javascript file, max  
> crashes.
> Even when the metro is off.
>
> With other patches including javascript I did not experience this.
> There i could edit and recompile with the patch open and even when  
> running.
> very helpful when exploring.
>
> I have tried to isolate the problem and I am led to believe that it is
> the JitterListener that is causing the crash.
> If I remove the JitterListener, there are no crashes.
>
> The interesting thing is that the crash does not happen on the  
> first recompile,
> but always on the second.
>
> this happens with the internal js editor as well as with  
> textwrangler as the external editor.
>
> current workaround:
> close and reopen patch after every save of the js file.
>
> find below the details.
> -jennek
> =========
>
> steps to reproduce:
> open 47jJitterListener.pat
> open js file by double clicking the js object.
> insert a post statement in function bang
> save file
> turn metro on
> observe posts are in effect
> turn metro off
> insert another post in function bang
> save file
> max crashes
>
> as a reference try this:
> close patch
> comment out the line
> var mylistener = new JitterListener(mywindow.getregisteredname(),  
> thecallback);
> in another text editor
> reopen patch
> edit js file as much as you like.
> no crashes like before.
>
>
> Partial crash log appended.
> This is on MacBookPro 10.4.7
> max 4.6/jitter1.6
>
>
> Date/Time:      2006-08-27 02:20:42.361 +0000
> OS Version:     10.4.7 (Build 8J2135a)
> Report Version: 4
>
> Command: MaxMSP
> Path:    /Applications/MaxMSP 4.6/MaxMSP.app/Contents/MacOS/MaxMSP
> Parent:  WindowServer [59]
>
> Version: ??? (4.6)
>
> PID:    25225
> Thread: 0
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000058
>
> Thread 0 Crashed:
> 0   com.cycling74.MaxJSRef         	0x315b4175 js_GetSlotThreadSafe  
> + 54
> 1   com.cycling74.MaxJSRef         	0x315b2ec0 js_Invoke + 554
> 2   com.cycling74.MaxJSRef         	0x315b35cb js_InternalInvoke + 178
> 3   com.cycling74.MaxJSRef         	0x3158694f JS_CallFunction + 64
> 4   com.cycling74.jsjitter         	0x31606844  
> jsjitterlistener_callback + 787 (bundle1.s:110)
> 5   com.cycling74.JitterAPI        	0x163e66aa jit_listener_notify  
> + 604
> 6   com.cycling74.MaxMSP46         	0x0011d2d7 object_method + 1431  
> (obex.c:798)
> 7   com.cycling74.MaxMSP46         	0x000df7a3 linklist_methodall +  
> 217 (linklist.c:887)
> 8   com.cycling74.MaxMSP46         	0x0011cafd object_notify + 109  
> (obex.c:1581)
> 9   com.cycling74.MaxMSP46         	0x0011d48f  
> object_attr_setvalueof + 285 (obex.c:1183)
> 10  com.cycling74.MaxAPI           	0x019e2149  
> object_attr_setvalueof + 51
> 11  com.cycling74.jsjitter         	0x31607dbd  
> jsjitterwrap_SetProperty + 204 (bundle1.s:110)
> 12  com.cycling74.MaxJSRef         	0x315ceb97 js_SetProperty + 1410
> 13  com.cycling74.MaxJSRef         	0x315af3ce js_Interpret + 25730
> 14  com.cycling74.MaxJSRef         	0x315b2c30 js_Execute + 477
> 15  com.cycling74.MaxJSRef         	0x315867e9 JS_ExecuteScript + 55
> 16  com.cycling74.js               	0x3173fbb1 js_eval + 816  
> (bundle1.s:110)
> 17  com.cycling74.js               	0x3173fc4e js_compile + 62  
> (bundle1.s:110)
> 18  com.cycling74.js               	0x3173fce6 js_filechanged + 130  
> (bundle1.s:110)
> 19  com.cycling74.MaxMSP46         	0x00114a00 filewatcher_check 
> (_filewatcher*) + 148 (filewatcher.c:144)
> 20  com.cycling74.MaxMSP46         	0x000584b3 sched_dequeue + 129  
> (sched.c:351)
> 21  com.cycling74.MaxMSP46         	0x00025cdd max_doeventtimerproc  
> + 101 (main.c:645)
> 22  com.cycling74.MaxMSP46         	0x00025d9b max_eventtimerproc +  
> 35 (main.c:691)
> 23  com.apple.HIToolbox            	0x92f3a8c2 TimerVector + 31
> 24  com.apple.CoreFoundation       	0x90823bc9 CFRunLoopRunSpecific  
> + 3341
> 25  com.apple.CoreFoundation       	0x90822eb5 CFRunLoopRunInMode + 61
> 26  com.apple.HIToolbox            	0x92f02b90  
> RunCurrentEventLoopInMode + 285
> 27  com.apple.HIToolbox            	0x92f02297  
> ReceiveNextEventCommon + 385
> 28  com.apple.HIToolbox            	0x92f4a929 _AcquireNextEvent + 58
> 29  com.apple.HIToolbox            	0x92f4a774  
> RunApplicationEventLoop + 150
> 30  com.cycling74.MaxMSP46         	0x0002683a app_run + 52 (main.c: 
> 1458)
> 31  com.cycling74.MaxMSP46         	0x00026ae4 main + 680 (main.c:415)
> 32  com.cycling74.MaxMSP46         	0x00001de2 _start + 228 (crt.c: 
> 272)
> 33  com.cycling74.MaxMSP46         	0x00001cfd start + 41
>

I get the same thing. JitterListener probably needs to be explicitly

garbage collected to prevent this from happening.

> I posted the problem report below a week ago, but I have had no reaction.

> Is there anybody out there willing to confirm or contradict my findings?

> is it just me (or my configuration) and can it be mended?

> it is getting very annoying to develop with JitterListener

> On 27-aug-2006, at 2:41, jennek geels wrote:

> Most of the times when I reload/recompile the javascript file, max crashes.

> There i could edit and recompile with the patch open and even when running.

> The interesting thing is that the crash does not happen on the first

> this happens with the internal js editor as well as with textwrangler as the

I get the same thing.  JitterListener probably needs to be explicitly
garbage collected to prevent this from happening.

On 9/4/06, jennek geels  wrote:
>
> hi,
> I posted the problem report below a week ago, but I have had no reaction.
> Is there anybody out there willing to confirm or contradict my findings?
> is it just me (or my configuration) and can it be mended?
> it is getting very annoying to develop with JitterListener
> thanks
> -jennek
>
>
> On 27-aug-2006, at 2:41, jennek geels wrote:
>
> Hi,
>
> I have been toying with Jitter Tutorial example 47.
> Most of the times when I reload/recompile the javascript file, max crashes.
> Even when the metro is off.
>
> With other patches including javascript I did not experience this.
> There i could edit and recompile with the patch open and even when running.
> very helpful when exploring.
>
> I have tried to isolate the problem and I am led to believe that it is
> the JitterListener that is causing the crash.
> If I remove the JitterListener, there are no crashes.
>
> The interesting thing is that the crash does not happen on the first
> recompile,
> but always on the second.
>
> this happens with the internal js editor as well as with textwrangler as the
> external editor.
>
> current workaround:
> close and reopen patch after every save of the js file.
>
> find below the details.
> -jennek
> =========
>
> steps to reproduce:
> open 47jJitterListener.pat
> open js file by double clicking the js object.
> insert a post statement in function bang
> save file
> turn metro on
> observe posts are in effect
> turn metro off
> insert another post in function bang
> save file
> max crashes
>
> as a reference try this:
> close patch
> comment out the line
> var mylistener = new JitterListener(mywindow.getregisteredname(),
> thecallback);
> in another text editor
> reopen patch
> edit js file as much as you like.
> no crashes like before.
>
>
> Partial crash log appended.
> This is on MacBookPro 10.4.7
> max 4.6/jitter1.6
>
>
> Date/Time:      2006-08-27 02:20:42.361 +0000
> OS Version:     10.4.7 (Build 8J2135a)
> Report Version: 4
>
> Command: MaxMSP
> Path:    /Applications/MaxMSP
> 4.6/MaxMSP.app/Contents/MacOS/MaxMSP
> Parent:  WindowServer [59]
>
> Version: ??? (4.6)
>
> PID:    25225
> Thread: 0
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000058
>
> Thread 0 Crashed:
> 0   com.cycling74.MaxJSRef         0x315b4175 js_GetSlotThreadSafe + 54
> 1   com.cycling74.MaxJSRef         0x315b2ec0 js_Invoke + 554
> 2   com.cycling74.MaxJSRef         0x315b35cb js_InternalInvoke + 178
> 3   com.cycling74.MaxJSRef         0x3158694f JS_CallFunction + 64
> 4   com.cycling74.jsjitter         0x31606844 jsjitterlistener_callback +
> 787 (bundle1.s:110)
> 5   com.cycling74.JitterAPI        0x163e66aa jit_listener_notify + 604
> 6   com.cycling74.MaxMSP46         0x0011d2d7 object_method + 1431
> (obex.c:798)
> 7   com.cycling74.MaxMSP46         0x000df7a3 linklist_methodall + 217
> (linklist.c:887)
> 8   com.cycling74.MaxMSP46         0x0011cafd object_notify + 109
> (obex.c:1581)
> 9   com.cycling74.MaxMSP46         0x0011d48f object_attr_setvalueof + 285
> (obex.c:1183)
> 10  com.cycling74.MaxAPI           0x019e2149 object_attr_setvalueof + 51
> 11  com.cycling74.jsjitter         0x31607dbd jsjitterwrap_SetProperty + 204
> (bundle1.s:110)
> 12  com.cycling74.MaxJSRef         0x315ceb97 js_SetProperty + 1410
> 13  com.cycling74.MaxJSRef         0x315af3ce js_Interpret + 25730
> 14  com.cycling74.MaxJSRef         0x315b2c30 js_Execute + 477
> 15  com.cycling74.MaxJSRef         0x315867e9 JS_ExecuteScript + 55
> 16  com.cycling74.js               0x3173fbb1 js_eval + 816 (bundle1.s:110)
> 17  com.cycling74.js               0x3173fc4e js_compile + 62
> (bundle1.s:110)
> 18  com.cycling74.js               0x3173fce6 js_filechanged + 130
> (bundle1.s:110)
> 19  com.cycling74.MaxMSP46         0x00114a00
> filewatcher_check(_filewatcher*) + 148 (filewatcher.c:144)
> 20  com.cycling74.MaxMSP46         0x000584b3 sched_dequeue + 129
> (sched.c:351)
> 21  com.cycling74.MaxMSP46         0x00025cdd max_doeventtimerproc + 101
> (main.c:645)
> 22  com.cycling74.MaxMSP46         0x00025d9b max_eventtimerproc + 35
> (main.c:691)
> 23  com.apple.HIToolbox            0x92f3a8c2 TimerVector + 31
> 24  com.apple.CoreFoundation       0x90823bc9 CFRunLoopRunSpecific + 3341
> 25  com.apple.CoreFoundation       0x90822eb5 CFRunLoopRunInMode + 61
> 26  com.apple.HIToolbox            0x92f02b90 RunCurrentEventLoopInMode +
> 285
> 27  com.apple.HIToolbox            0x92f02297 ReceiveNextEventCommon + 385
> 28  com.apple.HIToolbox            0x92f4a929 _AcquireNextEvent + 58
> 29  com.apple.HIToolbox            0x92f4a774 RunApplicationEventLoop + 150
> 30  com.cycling74.MaxMSP46         0x0002683a app_run + 52 (main.c:1458)
> 31  com.cycling74.MaxMSP46         0x00026ae4 main + 680 (main.c:415)
> 32  com.cycling74.MaxMSP46         0x00001de2 _start + 228 (crt.c:272)
> 33  com.cycling74.MaxMSP46         0x00001cfd start + 41
>
>
>
>
>
>


it is either that, or there may be a bug in the destructor which 

is there a way I can force the garbage to be collected?

On 4-sep-2006, at 21:43, Wesley Smith wrote:

> I get the same thing. JitterListener probably needs to be explicitly

> garbage collected to prevent this from happening.

>> I posted the problem report below a week ago, but I have had no 

>> Is there anybody out there willing to confirm or contradict my 

>> is it just me (or my configuration) and can it be mended?

>> it is getting very annoying to develop with JitterListener

>> On 27-aug-2006, at 2:41, jennek geels wrote:

>> I have been toying with Jitter Tutorial example 47.

>> Most of the times when I reload/recompile the javascript file, max 

>> With other patches including javascript I did not experience this.

>> There i could edit and recompile with the patch open and even when 

>> I have tried to isolate the problem and I am led to believe that 

>> the JitterListener that is causing the crash.

>> If I remove the JitterListener, there are no crashes.

>> The interesting thing is that the crash does not happen on the first

>> this happens with the internal js editor as well as with 

>> close and reopen patch after every save of the js file.

Thank you Wes, for your quick reply.
it is either that, or there may be a bug in the destructor which  
brings down max.

is there a way I can force the garbage to be collected?
-jennek

> I get the same thing.  JitterListener probably needs to be explicitly
> garbage collected to prevent this from happening.
>
> wes
>
> On 9/4/06, jennek geels  wrote:
>>
>> hi,
>> I posted the problem report below a week ago, but I have had no  
>> reaction.
>> Is there anybody out there willing to confirm or contradict my  
>> findings?
>> is it just me (or my configuration) and can it be mended?
>> it is getting very annoying to develop with JitterListener
>> thanks
>> -jennek
>>
>>
>> On 27-aug-2006, at 2:41, jennek geels wrote:
>>
>> Hi,
>>
>> I have been toying with Jitter Tutorial example 47.
>> Most of the times when I reload/recompile the javascript file, max  
>> crashes.
>> Even when the metro is off.
>>
>> With other patches including javascript I did not experience this.
>> There i could edit and recompile with the patch open and even when  
>> running.
>> very helpful when exploring.
>>
>> I have tried to isolate the problem and I am led to believe that  
>> it is
>> the JitterListener that is causing the crash.
>> If I remove the JitterListener, there are no crashes.
>>
>> The interesting thing is that the crash does not happen on the first
>> recompile,
>> but always on the second.
>>
>> this happens with the internal js editor as well as with  
>> textwrangler as the
>> external editor.
>>
>> current workaround:
>> close and reopen patch after every save of the js file.
>>
>> find below the details.
>> -jennek
>> =========
>>
>> steps to reproduce:
>> open 47jJitterListener.pat
>> open js file by double clicking the js object.
>> insert a post statement in function bang
>> save file
>> turn metro on
>> observe posts are in effect
>> turn metro off
>> insert another post in function bang
>> save file
>> max crashes
>>
>> as a reference try this:
>> close patch
>> comment out the line
>> var mylistener = new JitterListener(mywindow.getregisteredname(),
>> thecallback);
>> in another text editor
>> reopen patch
>> edit js file as much as you like.
>> no crashes like before.
>>
>>
>> Partial crash log appended.
>> This is on MacBookPro 10.4.7
>> max 4.6/jitter1.6
>>
>>
>> Date/Time:      2006-08-27 02:20:42.361 +0000
>> OS Version:     10.4.7 (Build 8J2135a)
>> Report Version: 4
>>
>> Command: MaxMSP
>> Path:    /Applications/MaxMSP
>> 4.6/MaxMSP.app/Contents/MacOS/MaxMSP
>> Parent:  WindowServer [59]
>>
>> Version: ??? (4.6)
>>
>> PID:    25225
>> Thread: 0
>>
>> Exception:  EXC_BAD_ACCESS (0x0001)
>> Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000058
>>
>> Thread 0 Crashed:
>> 0   com.cycling74.MaxJSRef         0x315b4175 js_GetSlotThreadSafe  
>> + 54
>> 1   com.cycling74.MaxJSRef         0x315b2ec0 js_Invoke + 554
>> 2   com.cycling74.MaxJSRef         0x315b35cb js_InternalInvoke + 178
>> 3   com.cycling74.MaxJSRef         0x3158694f JS_CallFunction + 64
>> 4   com.cycling74.jsjitter         0x31606844  
>> jsjitterlistener_callback +
>> 787 (bundle1.s:110)
>> 5   com.cycling74.JitterAPI        0x163e66aa jit_listener_notify  
>> + 604
>> 6   com.cycling74.MaxMSP46         0x0011d2d7 object_method + 1431
>> (obex.c:798)
>> 7   com.cycling74.MaxMSP46         0x000df7a3 linklist_methodall +  
>> 217
>> (linklist.c:887)
>> 8   com.cycling74.MaxMSP46         0x0011cafd object_notify + 109
>> (obex.c:1581)
>> 9   com.cycling74.MaxMSP46         0x0011d48f  
>> object_attr_setvalueof + 285
>> (obex.c:1183)
>> 10  com.cycling74.MaxAPI           0x019e2149  
>> object_attr_setvalueof + 51
>> 11  com.cycling74.jsjitter         0x31607dbd  
>> jsjitterwrap_SetProperty + 204
>> (bundle1.s:110)
>> 12  com.cycling74.MaxJSRef         0x315ceb97 js_SetProperty + 1410
>> 13  com.cycling74.MaxJSRef         0x315af3ce js_Interpret + 25730
>> 14  com.cycling74.MaxJSRef         0x315b2c30 js_Execute + 477
>> 15  com.cycling74.MaxJSRef         0x315867e9 JS_ExecuteScript + 55
>> 16  com.cycling74.js               0x3173fbb1 js_eval + 816  
>> (bundle1.s:110)
>> 17  com.cycling74.js               0x3173fc4e js_compile + 62
>> (bundle1.s:110)
>> 18  com.cycling74.js               0x3173fce6 js_filechanged + 130
>> (bundle1.s:110)
>> 19  com.cycling74.MaxMSP46         0x00114a00
>> filewatcher_check(_filewatcher*) + 148 (filewatcher.c:144)
>> 20  com.cycling74.MaxMSP46         0x000584b3 sched_dequeue + 129
>> (sched.c:351)
>> 21  com.cycling74.MaxMSP46         0x00025cdd max_doeventtimerproc  
>> + 101
>> (main.c:645)
>> 22  com.cycling74.MaxMSP46         0x00025d9b max_eventtimerproc + 35
>> (main.c:691)
>> 23  com.apple.HIToolbox            0x92f3a8c2 TimerVector + 31
>> 24  com.apple.CoreFoundation       0x90823bc9 CFRunLoopRunSpecific  
>> + 3341
>> 25  com.apple.CoreFoundation       0x90822eb5 CFRunLoopRunInMode + 61
>> 26  com.apple.HIToolbox            0x92f02b90  
>> RunCurrentEventLoopInMode +
>> 285
>> 27  com.apple.HIToolbox            0x92f02297  
>> ReceiveNextEventCommon + 385
>> 28  com.apple.HIToolbox            0x92f4a929 _AcquireNextEvent + 58
>> 29  com.apple.HIToolbox            0x92f4a774  
>> RunApplicationEventLoop + 150
>> 30  com.cycling74.MaxMSP46         0x0002683a app_run + 52 (main.c: 
>> 1458)
>> 31  com.cycling74.MaxMSP46         0x00026ae4 main + 680 (main.c:415)
>> 32  com.cycling74.MaxMSP46         0x00001de2 _start + 228 (crt.c: 
>> 272)
>> 33  com.cycling74.MaxMSP46         0x00001cfd start + 41
>>
>>
>>
>>
>>
>>
>


>From a post in javascript-dev on "how to free a matrix":

"As I believe is mentioned in the MaxMSP mailing list archives, it is

mymatrix.freepeer() to free the C peer object. Same is true for

Sketch, and Image. The general problem is that the JS GC doesn't know

about the C peer's memory and doesn't prioritize the collection of JS

garbage which is small despite the C peer's memory. So for these

cases you need to free the peer (or explicitly run the GC, which

happens to happen in new JitterObject() FWIW)."

I don't know if you've noticed, but sometimes when you have an opengl

patch going and hit command+Q, occasionaly it will crash max because

the opengl context disappears and the renderer doesn't get the signal

and this accesses invalid memory. The JitterListener crash is related

I beleive. Hopefully the above advice will help you out. Make sure

to call freepeer before anything else when the JS rebuilds.

> it is either that, or there may be a bug in the destructor which

> is there a way I can force the garbage to be collected?

> On 4-sep-2006, at 21:43, Wesley Smith wrote:

> > I get the same thing. JitterListener probably needs to be explicitly

> > garbage collected to prevent this from happening.

> >> I posted the problem report below a week ago, but I have had no

> >> Is there anybody out there willing to confirm or contradict my

> >> is it just me (or my configuration) and can it be mended?

> >> it is getting very annoying to develop with JitterListener

> >> On 27-aug-2006, at 2:41, jennek geels wrote:

> >> I have been toying with Jitter Tutorial example 47.

> >> Most of the times when I reload/recompile the javascript file, max

> >> With other patches including javascript I did not experience this.

> >> There i could edit and recompile with the patch open and even when

> >> I have tried to isolate the problem and I am led to believe that

> >> the JitterListener that is causing the crash.

> >> If I remove the JitterListener, there are no crashes.

> >> The interesting thing is that the crash does not happen on the first

"As I believe is mentioned in the MaxMSP mailing list archives, it is
mymatrix.freepeer() to free the C peer object. Same is true for
Sketch, and Image. The general problem is that the JS GC doesn't know
about the C peer's memory and doesn't prioritize the collection of JS
garbage which is small despite the C peer's memory. So for these
cases you need to free the peer (or explicitly run the GC, which
happens to happen in new JitterObject() FWIW)."

I don't know if you've noticed, but sometimes when you have an opengl
patch going and hit command+Q, occasionaly it will crash max because
the opengl context disappears and the renderer doesn't get the signal
and this accesses invalid memory.  The JitterListener crash is related
I beleive.  Hopefully the above advice will help you out.  Make sure
to call freepeer before anything else when the JS rebuilds.

On 9/4/06, jennek geels  wrote:
> Thank you Wes, for your quick reply.
> it is either that, or there may be a bug in the destructor which
> brings down max.
>
> is there a way I can force the garbage to be collected?
> -jennek
>
> On 4-sep-2006, at 21:43, Wesley Smith wrote:
>
> > I get the same thing.  JitterListener probably needs to be explicitly
> > garbage collected to prevent this from happening.
> >
> > wes
> >
> > On 9/4/06, jennek geels  wrote:
> >>
> >> hi,
> >> I posted the problem report below a week ago, but I have had no
> >> reaction.
> >> Is there anybody out there willing to confirm or contradict my
> >> findings?
> >> is it just me (or my configuration) and can it be mended?
> >> it is getting very annoying to develop with JitterListener
> >> thanks
> >> -jennek
> >>
> >>
> >> On 27-aug-2006, at 2:41, jennek geels wrote:
> >>
> >> Hi,
> >>
> >> I have been toying with Jitter Tutorial example 47.
> >> Most of the times when I reload/recompile the javascript file, max
> >> crashes.
> >> Even when the metro is off.
> >>
> >> With other patches including javascript I did not experience this.
> >> There i could edit and recompile with the patch open and even when
> >> running.
> >> very helpful when exploring.
> >>
> >> I have tried to isolate the problem and I am led to believe that
> >> it is
> >> the JitterListener that is causing the crash.
> >> If I remove the JitterListener, there are no crashes.
> >>
> >> The interesting thing is that the crash does not happen on the first
> >> recompile,
> >> but always on the second.
> >>
> >> this happens with the internal js editor as well as with
> >> textwrangler as the
> >> external editor.
> >>
> >> current workaround:
> >> close and reopen patch after every save of the js file.
> >>
> >> find below the details.
> >> -jennek
> >> =========
> >>
> >> steps to reproduce:
> >> open 47jJitterListener.pat
> >> open js file by double clicking the js object.
> >> insert a post statement in function bang
> >> save file
> >> turn metro on
> >> observe posts are in effect
> >> turn metro off
> >> insert another post in function bang
> >> save file
> >> max crashes
> >>
> >> as a reference try this:
> >> close patch
> >> comment out the line
> >> var mylistener = new JitterListener(mywindow.getregisteredname(),
> >> thecallback);
> >> in another text editor
> >> reopen patch
> >> edit js file as much as you like.
> >> no crashes like before.
> >>
> >>
> >> Partial crash log appended.
> >> This is on MacBookPro 10.4.7
> >> max 4.6/jitter1.6
> >>
> >>
> >> Date/Time:      2006-08-27 02:20:42.361 +0000
> >> OS Version:     10.4.7 (Build 8J2135a)
> >> Report Version: 4
> >>
> >> Command: MaxMSP
> >> Path:    /Applications/MaxMSP
> >> 4.6/MaxMSP.app/Contents/MacOS/MaxMSP
> >> Parent:  WindowServer [59]
> >>
> >> Version: ??? (4.6)
> >>
> >> PID:    25225
> >> Thread: 0
> >>
> >> Exception:  EXC_BAD_ACCESS (0x0001)
> >> Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000058
> >>
> >> Thread 0 Crashed:
> >> 0   com.cycling74.MaxJSRef         0x315b4175 js_GetSlotThreadSafe
> >> + 54
> >> 1   com.cycling74.MaxJSRef         0x315b2ec0 js_Invoke + 554
> >> 2   com.cycling74.MaxJSRef         0x315b35cb js_InternalInvoke + 178
> >> 3   com.cycling74.MaxJSRef         0x3158694f JS_CallFunction + 64
> >> 4   com.cycling74.jsjitter         0x31606844
> >> jsjitterlistener_callback +
> >> 787 (bundle1.s:110)
> >> 5   com.cycling74.JitterAPI        0x163e66aa jit_listener_notify
> >> + 604
> >> 6   com.cycling74.MaxMSP46         0x0011d2d7 object_method + 1431
> >> (obex.c:798)
> >> 7   com.cycling74.MaxMSP46         0x000df7a3 linklist_methodall +
> >> 217
> >> (linklist.c:887)
> >> 8   com.cycling74.MaxMSP46         0x0011cafd object_notify + 109
> >> (obex.c:1581)
> >> 9   com.cycling74.MaxMSP46         0x0011d48f
> >> object_attr_setvalueof + 285
> >> (obex.c:1183)
> >> 10  com.cycling74.MaxAPI           0x019e2149
> >> object_attr_setvalueof + 51
> >> 11  com.cycling74.jsjitter         0x31607dbd
> >> jsjitterwrap_SetProperty + 204
> >> (bundle1.s:110)
> >> 12  com.cycling74.MaxJSRef         0x315ceb97 js_SetProperty + 1410
> >> 13  com.cycling74.MaxJSRef         0x315af3ce js_Interpret + 25730
> >> 14  com.cycling74.MaxJSRef         0x315b2c30 js_Execute + 477
> >> 15  com.cycling74.MaxJSRef         0x315867e9 JS_ExecuteScript + 55
> >> 16  com.cycling74.js               0x3173fbb1 js_eval + 816
> >> (bundle1.s:110)
> >> 17  com.cycling74.js               0x3173fc4e js_compile + 62
> >> (bundle1.s:110)
> >> 18  com.cycling74.js               0x3173fce6 js_filechanged + 130
> >> (bundle1.s:110)
> >> 19  com.cycling74.MaxMSP46         0x00114a00
> >> filewatcher_check(_filewatcher*) + 148 (filewatcher.c:144)
> >> 20  com.cycling74.MaxMSP46         0x000584b3 sched_dequeue + 129
> >> (sched.c:351)
> >> 21  com.cycling74.MaxMSP46         0x00025cdd max_doeventtimerproc
> >> + 101
> >> (main.c:645)
> >> 22  com.cycling74.MaxMSP46         0x00025d9b max_eventtimerproc + 35
> >> (main.c:691)
> >> 23  com.apple.HIToolbox            0x92f3a8c2 TimerVector + 31
> >> 24  com.apple.CoreFoundation       0x90823bc9 CFRunLoopRunSpecific
> >> + 3341
> >> 25  com.apple.CoreFoundation       0x90822eb5 CFRunLoopRunInMode + 61
> >> 26  com.apple.HIToolbox            0x92f02b90
> >> RunCurrentEventLoopInMode +
> >> 285
> >> 27  com.apple.HIToolbox            0x92f02297
> >> ReceiveNextEventCommon + 385
> >> 28  com.apple.HIToolbox            0x92f4a929 _AcquireNextEvent + 58
> >> 29  com.apple.HIToolbox            0x92f4a774
> >> RunApplicationEventLoop + 150
> >> 30  com.cycling74.MaxMSP46         0x0002683a app_run + 52 (main.c:
> >> 1458)
> >> 31  com.cycling74.MaxMSP46         0x00026ae4 main + 680 (main.c:415)
> >> 32  com.cycling74.MaxMSP46         0x00001de2 _start + 228 (crt.c:
> >> 272)
> >> 33  com.cycling74.MaxMSP46         0x00001cfd start + 41
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
>


Thanks for this report. This is a tricky scenario to try and fix due 

to the nature of garbage collection and the current JS object's 

design which only removes and garbage collects *function* properties 

on recompile. I am going to investigate a potential fix for 

JitterListener, and also ask David Z. if he has any objection to 

freeing other non function properties on recompile.

Unfortunately, the JitterListener object doesn't have a freepeer 

method, however, you can stop it from listening by stting the 

subjectname attribute to the empty string. So you should be able to 

add the following line to the top of your code to eliminate the 

crashes until we are able to address this larger issue:

More generally, I might suggest the following strategy for enforcing 

the behavior I am going to propose to David Z. with the existing 

version. However, it might still exhibit problems in the case that 

the callback and the jit.window are freed prior to to freeing the 

JitterListener (ouch, so you still want to add the above line, most 

likely, will try to come up with something better in the future).

1. set all your JitterObject variables to null before assigning them 

non-null values. This may be more easily accomplished by declaring 

all globals in the scope of a single object, as demonstrated below.

2. exploit the JitterMatrix() or JitterObject() constructor as a gc() 

// create one global object (marks old one and all children not

// parented elsewhere for garbage collection)

    var tmp = new JitterMatrix(1,"char",1);

// call out GC function to free all our old objects

// instantiate our objects in the context of the _g object

// so that they are easily freed with the above GC strategy

Thanks for this report. This is a tricky scenario to try and fix due  
to the nature of garbage collection and the current JS object's  
design which only removes and garbage collects *function* properties  
on recompile. I am going to investigate a potential fix for  
JitterListener, and also ask David Z. if he has any objection to  
freeing other non function properties on recompile.

Unfortunately, the JitterListener object doesn't have a freepeer  
method, however, you can stop it from listening by stting the  
subjectname attribute to the empty string. So you should be able to  
add the following line to the top of your code to eliminate the  
crashes until we are able to address this larger issue:

if (mylistener)
	mylistener.subjectname = "";

More generally, I might suggest the following strategy for enforcing  
the behavior I am going to propose to David Z. with the existing  
version. However, it might still exhibit problems in the case that  
the callback and the jit.window are freed prior to to freeing the  
JitterListener (ouch, so you still want to add the above line, most  
likely, will try to come up with something better in the future).

1. set all your JitterObject variables to null before assigning them  
non-null values. This may be more easily accomplished by declaring  
all globals in the scope of a single object, as demonstrated below.

2. exploit the JitterMatrix() or JitterObject() constructor as a gc()  
call.

// create one global object (marks old one and all children not
// parented elsewhere for garbage collection)
var _g = new Object();

// define our GC function
function garbage_collect() {
	var tmp = new JitterMatrix(1,"char",1);
}

// call out GC function to free all our old objects
garbage_collect();

// instantiate our objects in the context of the _g object
// so that they are easily freed with the above GC strategy
_g.myvariable1 = new JitterObject(...);
_g.myvariable2 = new JitterObject(...);
_g.myvariable3 = new JitterObject(...);

the first one works for me. I have not yet tried the second.

This solution really builds on knowledge of the internal workings,

so I really appreciate your contribution here.

On 7-sep-2006, at 0:27, Joshua Kit Clayton wrote:

> Thanks for this report. This is a tricky scenario to try and fix 

> due to the nature of garbage collection and the current JS object's 

> design which only removes and garbage collects *function* 

> properties on recompile. I am going to investigate a potential fix 

> for JitterListener, and also ask David Z. if he has any objection 

recompiling with JitterListener leads to crash