barry threw

I am working on splitting up a Jitter patch into Max and Max Runtime 

sections in order to take advantage of multiprocessors. My patches work 

correctly when all loading into Max, but as soon as one of them is 

loading into Max Runtime they function incorrectly. Jitter matrices are 

being passed from the main Max section to the Runtime section and back 

via jit.net.send (on an arbitrary port 8000 and 8001). As soon as 

information begins traveling over this connection, the patch in the 

Runtime hangs. The Max section is unaffected.

However, this hang does not occur when all patches are loading inside of 

This crash happens on both Windows XP SP 2 w/ Max 4.5.7 (Jitter 1.5.2) 

and Mac OS X 10.4.7 with Max 4.5.7 and Jitter 1.5.3 Beta.

I apologize for not being able to provide an example patch right now, 

but I am working on making the issue appear in as small a circumstance 

Via the thread on the Max list about Thread viewer, here is the stack 

from the main thread, for Max Runtime up until it hangs:

trigger_iterate__FP6unpackldP6symbolP6symbolsP4atoms

trigger_anything__FP6unpackP6symbolsP4atom

barry threw :: sound | (if you would see the stars clearly,

 | look hard at the surrounding darkness)

I am working on splitting up a Jitter patch into Max and Max Runtime 
sections in order to take advantage of multiprocessors.  My patches work 
correctly when all loading into Max, but as soon as one of them is 
loading into Max Runtime they function incorrectly.  Jitter matrices are 
being passed from the main Max section to the Runtime section and back 
via jit.net.send (on an arbitrary port 8000 and 8001).  As soon as 
information begins traveling over this connection, the patch in the 
Runtime hangs.  The Max section is unaffected.

However, this hang does not occur when all patches are loading inside of 
full Max.

This crash happens on both Windows XP SP 2 w/ Max 4.5.7 (Jitter 1.5.2) 
and Mac OS X 10.4.7 with Max 4.5.7 and Jitter 1.5.3 Beta.

I apologize for not being able to provide an example patch right now, 
but I am working on making the issue appear in as small a circumstance 
as possible.

Via the thread on the Max list about Thread viewer, here is the stack 
from the main thread, for Max Runtime up until it hangs:

0x194cc58
0x203dc07c
0x203dcce8
object_method
0x4c03b1c
0x4ba0c80
0x4ba0be0
typedmess_fun
outlet_anything
0x200aa1b8
0x4ba0f20
0x4ba0488
0x4ba0e6c
typedmess_fun
typedmess
0x200a9e8c
outlet_bang
trigger_iterate__FP6unpackldP6symbolP6symbolsP4atoms
trigger_anything__FP6unpackP6symbolsP4atom
typedmess_fun
outlet_anything
0x4be3350
0x4ba0f20
0x4ba0488
0x4ba0e6c
typedmess_fun
typedmess
0x4be3240
outlet_bang
trigger_iterate__FP6unpackldP6symbolP6symbolsP4atoms
trigger_anything__FP6unpackP6symbolsP4atom
typedmess_fun
outlet_anything
0x4be3350
0x99dfa2c
0x4be2fe0
0x99df890
typedmess_fun
outlet_anything
0x200aa1b8
0x200ab4f4
typedmess_fun
outlet_anything
0x4be3350
0x4be3060
typedmess_fun
outlet_anything
0x200aa1b8
0x200ab4f4
typedmess_fun
outlet_anything
typedmess_fun
typedmess
inlet_anything
typedmess_fun
outlet_anything
0x1fe94d9c
0x1fe94c9c
object_method
linklist_methodall
object_notify
0x4c04454
0x1fe97274
sched_dequeue
max_doeventtimerproc
max_eventtimerproc
__CFRunLoopDoTimer
__CFRunLoopRun
CFRunLoopRunSpecific
RunCurrentEventLoopInMode
ReceiveNextEventCommon
AcquireNextEventInMode
RunApplicationEventLoop
app_run
main

-- 
barry threw :: sound      |   (if you would see the stars clearly,
http://www.barrythrew.com |   look hard at the surrounding darkness)
bthrew(at)gmail(dot)com   |                       -Ooka Makoto
857-544-3967              |


crash-when-using-max-runtime

On Aug 31, 2006, at 2:37 PM, Barry Threw wrote:

> Via the thread on the Max list about Thread viewer, here is the 

> stack from the main thread, for Max Runtime up until it hangs:

Unfortunately this stack doesn't give us much information, since it 

is just for the most part just presenting addresses rather than 

function names. More details, including simple example patch etc 

would be necessary for us to investigate further.

>
> Via the thread on the Max list about Thread viewer, here is the  
> stack from the main thread, for Max Runtime up until it hangs:
>
> 0x194cc58
> 0x203dc07c
> 0x203dcce8
> object_method

Unfortunately this stack doesn't give us much information, since it  
is just for the most part just presenting addresses rather than  
function names. More details, including simple example patch etc  
would be necessary for us to investigate further.

Josh, the second section of this patch should look familiar. As I 

mentioned, open both of these in Max Full and it works fine. Open the 

second patch in Runtime and it crashes, regardless of OS.

> On Aug 31, 2006, at 2:37 PM, Barry Threw wrote:

>> Via the thread on the Max list about Thread viewer, here is the stack 

>> from the main thread, for Max Runtime up until it hangs:

> Unfortunately this stack doesn't give us much information, since it is 

> just for the most part just presenting addresses rather than function 

> names. More details, including simple example patch etc would be 

> necessary for us to investigate further.

Josh, the second section of this patch should look familiar.  As I 
mentioned, open both of these in Max Full and it works fine.  Open the 
second patch in Runtime and it crashes, regardless of OS.

Joshua Kit Clayton wrote:
>
> On Aug 31, 2006, at 2:37 PM, Barry Threw wrote:
>
>>
>> Via the thread on the Max list about Thread viewer, here is the stack 
>> from the main thread, for Max Runtime up until it hangs:
>>
>> 0x194cc58
>> 0x203dc07c
>> 0x203dcce8
>> object_method
>
> Unfortunately this stack doesn't give us much information, since it is 
> just for the most part just presenting addresses rather than function 
> names. More details, including simple example patch etc would be 
> necessary for us to investigate further.
>
> -Joshua
>

On Aug 31, 2006, at 4:34 PM, Barry Threw wrote:

> Josh, the second section of this patch should look familiar. As I 

> mentioned, open both of these in Max Full and it works fine. Open 

> the second patch in Runtime and it crashes, regardless of OS.

You're actually not deadlocking here, what doesn't happen if it's all 

in one application is that jit.matrix doesn't let any more matrices 

through while the other one is being processed (everything aside from 

the matrix being sent across the networking objects happens in the 

main application thread). In your patch, you are backlogging the 

slave patch by sending too many matrices and it's totally bogged down 

with trying to process matrices that you can hardly get a UI event in 

(in which case the OS gives a spinning wheel).

You will need to redesign your patch to either use a slower metro 

that doesn't overdrive the slave, or use some clever logic to not 

send another matrix until the last one is sent through. I've taken 

the time to build a version of your master patch that uses gates to 

only send one matrix until it hears back from the client.

However, I'd like to point out that using this older jit.gl.render 

strategy for the height field as well as rendering to a jit.matrix 

directly is going to be incredibly slow no matter what. (getting back 

to Keith's original thread on performance). I would recommend that 

you render to a HW context using the jit.gl.mesh example I posted for 

you guys and then read back the bits back to RAM via (@capture or 

jit.gl.render to_texture)->jit.gl.slab->jit.matrix or the 

jit.gl.sketch glreadpixels command. I've made a version of your 

client patch which uses to_texture->slab->jit.matrix, but this 

requires the latest jitter (1.6 XP or UB, or 1.5.3 CFM) to work 

And don't forget to get rid of all extra pwindows (or at least turn 

off the onscreen attribute for downscaled versions, as mentioned in 

jit.pwindow.help->tips) to get better performance once you're through 

> Ask and ye shall receive...
>
> Josh, the second section of this patch should look familiar.  As I  
> mentioned, open both of these in Max Full and it works fine.  Open  
> the second patch in Runtime and it crashes, regardless of OS.

You're actually not deadlocking here, what doesn't happen if it's all  
in one application is that jit.matrix doesn't let any more matrices  
through while the other one is being processed (everything aside from  
the matrix being sent across the networking objects happens in the  
main application thread). In your patch, you are backlogging the  
slave patch by sending too many matrices and it's totally bogged down  
with trying to process matrices that you can hardly get a UI event in  
(in which case the OS gives a spinning wheel).

You will need to redesign your patch to either use a slower metro  
that doesn't overdrive the slave, or use some clever logic to not  
send another matrix until the last one is sent through. I've taken  
the time to build a version of your master patch that uses gates to  
only send one matrix until it hears back from the client.

However, I'd like to point out that using this older jit.gl.render  
strategy for the height field as well as rendering to a jit.matrix  
directly is going to be incredibly slow no matter what. (getting back  
to Keith's original thread on performance). I would recommend that  
you render to a HW context using the jit.gl.mesh example I posted for  
you guys and then read back the bits back to RAM via (@capture or  
jit.gl.render to_texture)->jit.gl.slab->jit.matrix or the  
jit.gl.sketch glreadpixels command. I've made a version of your  
client patch which uses to_texture->slab->jit.matrix, but this  
requires the latest jitter (1.6 XP or UB, or 1.5.3 CFM) to work  
properly.

And don't forget to get rid of all extra pwindows (or at least turn  
off the onscreen attribute for downscaled versions, as mentioned in  
jit.pwindow.help->tips) to get better performance once you're through  
debugging.

The only reason we were not using your modified version at this point 

was because the effect wasn't quite the same and we didn't have the time 

to message it to reproduce the known effects we desired right now.

But that is our issue, not yours, I'm a fan of the new version.

> On Aug 31, 2006, at 4:34 PM, Barry Threw wrote:

>> Josh, the second section of this patch should look familiar. As I 

>> mentioned, open both of these in Max Full and it works fine. Open the 

>> second patch in Runtime and it crashes, regardless of OS.

> You're actually not deadlocking here, what doesn't happen if it's all in 

> one application is that jit.matrix doesn't let any more matrices through 

> while the other one is being processed (everything aside from the matrix 

> being sent across the networking objects happens in the main application 

> thread). In your patch, you are backlogging the slave patch by sending 

> too many matrices and it's totally bogged down with trying to process 

> matrices that you can hardly get a UI event in (in which case the OS 

> You will need to redesign your patch to either use a slower metro that 

> doesn't overdrive the slave, or use some clever logic to not send 

> another matrix until the last one is sent through. I've taken the time 

> to build a version of your master patch that uses gates to only send one 

> matrix until it hears back from the client.

> However, I'd like to point out that using this older jit.gl.render 

> strategy for the height field as well as rendering to a jit.matrix 

> directly is going to be incredibly slow no matter what. (getting back to 

> Keith's original thread on performance). I would recommend that you 

> render to a HW context using the jit.gl.mesh example I posted for you 

> guys and then read back the bits back to RAM via (@capture or 

> jit.gl.render to_texture)->jit.gl.slab->jit.matrix or the jit.gl.sketch 

> glreadpixels command. I've made a version of your client patch which 

> uses to_texture->slab->jit.matrix, but this requires the latest jitter 

> (1.6 XP or UB, or 1.5.3 CFM) to work properly.

> And don't forget to get rid of all extra pwindows (or at least turn off 

> the onscreen attribute for downscaled versions, as mentioned in 

> jit.pwindow.help->tips) to get better performance once you're through 

Thanks a lot.  I appreciate your support.

The only reason we were not using your modified version at this point 
was because the effect wasn't quite the same and we didn't have the time 
to message it to reproduce the known effects we desired right now.

Joshua Kit Clayton wrote:
>
> On Aug 31, 2006, at 4:34 PM, Barry Threw wrote:
>
>> Ask and ye shall receive...
>>
>> Josh, the second section of this patch should look familiar.  As I 
>> mentioned, open both of these in Max Full and it works fine.  Open the 
>> second patch in Runtime and it crashes, regardless of OS.
>
>
> You're actually not deadlocking here, what doesn't happen if it's all in 
> one application is that jit.matrix doesn't let any more matrices through 
> while the other one is being processed (everything aside from the matrix 
> being sent across the networking objects happens in the main application 
> thread). In your patch, you are backlogging the slave patch by sending 
> too many matrices and it's totally bogged down with trying to process 
> matrices that you can hardly get a UI event in (in which case the OS 
> gives a spinning wheel).
>
> You will need to redesign your patch to either use a slower metro that 
> doesn't overdrive the slave, or use some clever logic to not send 
> another matrix until the last one is sent through. I've taken the time 
> to build a version of your master patch that uses gates to only send one 
> matrix until it hears back from the client.
>
> However, I'd like to point out that using this older jit.gl.render 
> strategy for the height field as well as rendering to a jit.matrix 
> directly is going to be incredibly slow no matter what. (getting back to 
> Keith's original thread on performance). I would recommend that you 
> render to a HW context using the jit.gl.mesh example I posted for you 
> guys and then read back the bits back to RAM via (@capture or 
> jit.gl.render to_texture)->jit.gl.slab->jit.matrix or the jit.gl.sketch 
> glreadpixels command. I've made a version of your client patch which 
> uses to_texture->slab->jit.matrix, but this requires the latest jitter 
> (1.6 XP or UB, or 1.5.3 CFM) to work properly.
>
> And don't forget to get rid of all extra pwindows (or at least turn off 
> the onscreen attribute for downscaled versions, as mentioned in 
> jit.pwindow.help->tips) to get better performance once you're through 
> debugging.
>
> -Joshua
>
>
> MASTER_PATCH:
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P message 29 167 14 196617 1;
> #P newex 194 144 29 196617 t 1 l;
> #P newex 82 139 29 196617 t 0 l;
> #P newex 82 218 29 196617 gate;
> #P user jit.pwindow 213 208 82 62 0 0 0 0 1 0;
> #P flonum 129 29 35 9 0.5 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P toggle 82 29 15 0;
> #P newex 82 49 57 196617 metro 40;
> #P user jit.pwindow 119 209 82 62 0 0 0 0 1 0;
> #P message 171 29 50 196617 read;
> #B color 14;
> #P newex 82 73 76 196617 jit.qt.movie;
> #P newex 371 110 50 196617 t b s;
> #P message 257 290 53 196617 POLO!;
> #P newex 411 161 85 196617 print Vid.Return;
> #P flonum 481 133 50 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P toggle 429 130 28 0;
> #P newex 429 110 115 196617 route connected latency;
> #P newex 313 91 126 196617 jit.net.recv @port 7781;
> #B color 12;
> #P comment 187 352 21 196617 ms;
> #P flonum 134 350 50 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P toggle 82 347 28 0;
> #P newex 82 327 115 196617 route connected latency;
> #P newex 82 307 185 196617 jit.net.send @port 7780;
> #B color 12;
> #P window linecount 2;
> #P comment 229 31 100 196617 Just load a movie and play it.;
> #P comment 0 140 76 196617 turn on gate for first matrix;
> #P window linecount 3;
> #P comment 97 94 146 196617 for each matrix , close the gate until 
> we've heard back about the round trip , then open;
> #P connect 9 1 11 0;
> #P connect 9 0 10 0;
> #P connect 8 2 9 0;
> #P connect 14 1 12 0;
> #P connect 8 1 14 0;
> #P connect 13 0 3 1;
> #P fasten 14 0 13 0 376 283 262 283;
> #P connect 24 1 21 0;
> #P connect 8 0 24 0;
> #P connect 4 1 6 0;
> #P connect 20 0 18 1;
> #P connect 23 1 17 0;
> #P connect 23 1 22 1;
> #P connect 4 0 5 0;
> #P connect 3 0 4 0;
> #P connect 22 0 3 0;
> #P connect 23 0 22 0;
> #P connect 25 0 22 0;
> #P connect 24 0 22 0;
> #P connect 15 0 23 0;
> #P connect 18 0 15 0;
> #P connect 16 0 15 0;
> #P connect 19 0 18 0;
> #P window clipboard copycount 26;
>
>
>
> CLIENT_PATCH:
>
>
> #P toggle 799 445 15 0;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P message 788 470 44 196617 fsaa $1;
> #P newex 245 194 23 196617 t b;
> #P newex 226 82 29 196617 t b l;
> #P toggle 463 263 15 0;
> #P message 463 286 88 196617 poly_mode $1 $1;
> #P hidden newex 382 232 69 196617 loadmess 0.5;
> #P hidden newex 518 136 48 196617 loadbang;
> #P message 649 192 244 196617 exprfill 0 "norm[0]" , exprfill 1 
> "1.-norm[1]" , bang;
> #P newex 649 224 190 196617 jit.matrix texcoords 2 float32 320 240;
> #P message 461 170 222 196617 exprfill 0 "snorm[0]" , exprfill 1 
> "-snorm[1]" ,;
> #P newex 461 202 168 196617 jit.matrix geom 3 float32 320 240;
> #P flonum 380 257 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 340 258 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P flonum 298 258 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P newex 269 282 99 196617 pak scale 1. 1. 0.25;
> #P newex 268 145 180 196617 jit.gl.texture DispLocal @name mytex;
> #P newex 245 335 364 196617 jit.gl.mesh DispLocal @draw_mode tri_grid 
> @texture mytex @color 1. 1. 1. 1.;
> #P newex 245 213 211 196617 jit.pack 3 float32 320 240 @out_name geom;
> #P newex 245 169 203 196617 jit.matrix 1 float32 320 240 @planemap 2;
> #P newex 558 608 98 196617 jit.gl.slab DispLocal;
> #P newex 558 580 192 196617 jit.gl.texture DispLocal @name DispCopy;
> #P newex 685 490 287 196617 jit.window DispLocal @depthbuffer 1 @size 
> 320 240 @sync 0;
> #P user jit.fpsgui 494 685 60 196617 0;
> #P user jit.pwindow 134 73 82 62 0 0 0 0 1 0;
> #P user jit.pwindow 763 680 82 62 0 0 0 0 1 0;
> #P newex 313 66 73 196617 print Vid.Send;
> #P newex 477 86 31 196617 print;
> #P toggle 400 86 28 0;
> #P newex 400 66 87 196617 route connected;
> #P newex 226 42 185 196617 jit.net.recv @port 7780;
> #B color 12;
> #P newex 735 641 89 196617 loadmess MARCO!;
> #P comment 664 720 21 196617 ms;
> #P flonum 611 720 50 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
> #P toggle 559 720 15 0;
> #P newex 559 700 115 196617 route connected latency;
> #P newex 559 680 168 196617 jit.net.send @port 7781;
> #B color 12;
> #P newex 558 651 55 196617 jit.matrix;
> #P newex 555 405 50 196617 loadbang;
> #P window linecount 2;
> #P message 556 430 220 196617 lookat 0 0 0 , camera 0. -0.5 1.5 , 
> color 1. 1. 1. 0.5 , erase_color 0. 0. 0. 1. , depth_enable 1;
> #P window linecount 1;
> #P newex 559 504 109 196617 jit.gl.render DispLocal;
> #P newex 257 425 132 196617 t swap b drawclients erase;
> #P message 297 453 159 196617 usetexture DispCopy , to_texture;
> #P connect 5 0 19 0;
> #P connect 5 0 6 0;
> #P fasten 5 0 17 0 563 674 769 674;
> #P connect 42 0 41 0;
> #P connect 11 0 6 1;
> #P connect 41 0 20 0;
> #P connect 34 0 33 0;
> #P hidden connect 35 0 32 0;
> #P hidden connect 35 0 34 0;
> #P connect 7 1 9 0;
> #P connect 7 0 8 0;
> #P connect 6 0 7 0;
> #P connect 3 0 2 0;
> #P connect 0 0 2 0;
> #P connect 1 2 2 0;
> #P connect 1 3 2 0;
> #P connect 1 0 2 0;
> #P connect 22 0 5 0;
> #P connect 21 0 22 0;
> #P connect 1 1 0 0;
> #P connect 1 1 21 0;
> #P connect 4 0 3 0;
> #P connect 13 1 15 0;
> #P connect 38 0 37 0;
> #P connect 32 0 31 0;
> #P connect 23 0 40 0;
> #P connect 23 0 24 2;
> #P connect 13 0 14 0;
> #P connect 12 2 13 0;
> #P hidden connect 36 0 30 0;
> #P connect 30 0 27 3;
> #P connect 29 0 27 2;
> #P connect 12 1 16 0;
> #P connect 28 0 27 1;
> #P fasten 33 0 25 1 654 323 294 323;
> #P connect 39 1 23 0;
> #P connect 39 1 26 0;
> #P fasten 39 0 1 0 169 281 185 414;
> #P fasten 27 0 25 0 274 310 250 310;
> #P fasten 37 0 25 0 468 316 250 316;
> #P connect 24 0 25 0;
> #P connect 40 0 24 0;
> #P connect 12 0 39 0;
> #P connect 12 0 18 0;
> #P window clipboard copycount 43;
>
>
>
>
>

crash when using Max Runtime