Forums > Javascript

recompiling with JitterListener leads to crash

August 27, 2006 | 12:42 am

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 (0×0001)
Codes: KERN_PROTECTION_FAILURE (0×0002) at 0×00000058

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 0×31606844
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


September 4, 2006 | 9:33 pm

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 (0×0001)
> Codes: KERN_PROTECTION_FAILURE (0×0002) at 0×00000058
>
> 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 0×31606844
> 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
>


September 4, 2006 | 9:43 pm

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 (0×0001)
> Codes: KERN_PROTECTION_FAILURE (0×0002) at 0×00000058
>
> 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 0×31606844 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
>
>
>
>
>
>


September 4, 2006 | 9:58 pm

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 (0×0001)
>> Codes: KERN_PROTECTION_FAILURE (0×0002) at 0×00000058
>>
>> 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 0×31606844
>> 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
>>
>>
>>
>>
>>
>>
>


September 4, 2006 | 10:22 pm

>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.

wes

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 (0×0001)
> >> Codes: KERN_PROTECTION_FAILURE (0×0002) at 0×00000058
> >>
> >> 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 0×31606844
> >> 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
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
>


September 7, 2006 | 12:27 am

Hi Jennek,

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(…);

Hope this helps…

-Joshua


September 10, 2006 | 10:31 pm

Hi Joshua,

thanks for the solutions.
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.

-jennek

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

> Hi Jennek,
>
> 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(…);
>
>
> Hope this helps…
>
> -Joshua
>
>
>
>
>


October 22, 2007 | 10:01 pm

This is a tangent, but appropriate for this thread, for the sake of the archive.

I’ve had to do this:

listener.subjectname = "";
listener = new JitterListener(movarray[currentindex].getregisteredname(), thecallback);

when using a single listener (i.e., I’ve only declared "var listener;" at the head of my js) for an array of movies that I’m stepping thru. I don’t want to get into details, but it seems that in sequencing an array of movies, and I didn’t set the subject name to null, then the JitterListener didn’t seem to go away, and as I cycled thru the array of movies, there would be double reportage of loops.
I’d love to provide an example, but it is too tiresome to do. So if you are using what seems like a single JitterListener, but you are getting multiple loopreports, you may want to try the above.


Viewing 8 posts - 1 through 8 (of 8 total)