crash when using Max Runtime


    Aug 31 2006 | 9:37 pm
    Dear Interweb friends,
    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 |

    • Aug 31 2006 | 10:02 pm
      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
    • Aug 31 2006 | 11:34 pm
      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.
      Thanks for suffering for our art,
      ===========
      MaxFull.pat
      ===========
      max v2;
      ============
      Runtime.pat
      ============
      max v2;
      =============
      Thanks again,
      barry
      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
      >
      --
      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 |
    • Sep 01 2006 | 1:36 am
      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:
      CLIENT_PATCH:
    • Sep 01 2006 | 2:28 am
      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.
      But that is our issue, not yours, I'm a fan of the new version.
      Thanks again,
      barry
      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;
      >
      >
      >
      >
      >
      --
      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 |