strange


    Jun 09 2006 | 10:11 am
    I've been having a strange problem with mxj and my latest code abomination.
    Max freezes or crashes on the first test-run _after_ I re-compile and re-instantiate the mxj.
    Logout sometimes helps, and when it doesn't a restart always does. Once I restart, the patch runs as expected.
    I know it's impossible to say exactly without a code example, but the code is pretty huge... All I'm wondering about is where I might start looking for a cure for such a problem? Any ideas about what types of routines, data structures, etc. might present this strange behavior? A garbage collection thing maybe? I have a "clear" routine that resets/clears all data structures, which I always run before I close/re-open the patch.
    Thoughts?
    J.

    • Jun 09 2006 | 10:43 pm
      Are you doing any swing stuff? Are you on OS X?
      topher
    • Jun 10 2006 | 8:07 am
      hmm... I thought I replied to this yesterday, but it doesn't seem to have posted.
      Anyway, no, no swing. I'm on OS X, 10.4.6. I should mention that all of my previous experiences with hangs while working on this patch came down to problems with sflist~. Mostly related to overly ambitious preloading (too fast). I fixed that problem, and sflist~ is now calling the shots in terms of preload speed, so I can't imagine that's still the problem. I've been clearing the sflist~ before I close the patch as well, just to be safe.
      Is it possible for an sfplay~ to still maintain an errant preload, even when it's getting all its cues from one sflist~?
      Mind you, I don't see how a problem that presents itself after compiling could relate to sflist~. Dunno. Strange, as the post title suggests...
      J.
    • Jun 10 2006 | 12:51 pm
      I just found this in a older thread:
      >Actually if you do not recompile a class during a Max session all
      >instances of that class will be loaded by the same classloader. A
      >class will only be loaded by a new classloader if it changes.
      >Toph
      Do you think maybe there's something like this going on with my patch, only in the converse "if you _do_ recompile" situation?
      The reason I'm wondering is because I just loaded up my patch as a few AU plugins in Logic, and it turns out that there's some data creeping around between plugin instances -- all plugs are getting data from the last plugin instance loaded. So obviously something's getting passed around. VSTTDs: VST Transmitted Data.
      I've never quite gotten my head around how data is shared/not shared bewteen instances of mxj objects in plugins. Any hints/tips? Does this seem like it might be related to earlier crashes as well?
      J.
    • Jun 10 2006 | 1:24 pm
      I know, I know...
      it's kind of embarrassing how often I answer my own questions...
      Anyway, I found the shared data (VSTTD) bit; a poorly placed "static" declaration.
      I guess maybe this could cure the other problem, too? Dunno.
      J.
    • Jun 11 2006 | 11:11 am
      I'm still having what I think are constructor-related problems when using multiple plugin instances. Can anyone possibly simplify the "best practices" for keeping independent mxj-based plugins totally independent? I guess I'm really not sure how multiple instances of plugins interact with regard to the VM.
      J.
    • Jun 11 2006 | 12:09 pm
      Okay, I can load about 5 or 6 instances of the plug, then Logic crashes on Thread 0, with the following:
      Exception: EXC_BAD_ACCESS (0x0001)
      Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x27321e90
      Thread 0 Crashed:
      0 MaxPPC3.1 0x2726ecbc hashtab_store + 216
      1 MaxPPC3.1 0x27275a2c reg_object_namespace_fromsym + 92
      2 MaxPPC3.1 0x27275f60 object_register_unique + 84
      3 MaxPPC3.1 0x271cc1b4 patcher_uniqueboxname + 44
      4 MaxPPC3.1 0x271cc2f0 patcher_objectname + 32
      5 MaxPPC3.1 0x271b091c typedmess_fun + 1628
      6 MaxPPC3.1 0x271b004c typedmess + 84
      7 MaxPPC3.1 0x271b1318 aeval + 1116
      8 MaxPPC3.1 0x27198b24 bf_fastload + 636
      9 MaxPPC3.1 0x271a9200 lowload_type__FPcslsP4atoms + 480
      10 MaxPPC3.1 0x271a9928 fileload_extended + 160
      11 MaxPPC3.1 0x271a9848 fileload_type + 76
      12 MaxPPC3.1 0x272528ac xpcoll_loadentry + 52
      13 MaxPPC3.1 0x27252840 xpcoll_findload + 44
      14 MaxPPC3.1 0x27247940 linklist_funall + 80
      15 MaxPPC3.1 0x27252734 xpcoll_loadpatchers + 72
      16 MaxPPC3.1 0x2725222c xpcoll_load + 72
      17 0x1d0ce8c0 vstplug_loadfile + 792
      18 0x1d0ce3c4 vstplug_open + 504
      19 0x1d0c9d10 vstplug_load + 1156
      20 VNS_fuzzy_to_VST-build 0x02fcffa8 IntoVstPlugLib + 520
      21 VNS_fuzzy_to_VST-build 0x02fcf9a8 main + 792
      22 com.cycling74.PluggoAU 0x271603b4 PluggoAUEntry + 10332
      23 com.cycling74.PluggoAU 0x2715df98 PluggoAUEntry + 1088
      24 com.cycling74.PluggoAU 0x2715d598 dyld_stub_memchr + 655604424
      25 com.cycling74.PluggoAU 0x2715dbd0 PluggoAUEntry + 120
      26 ...ple.CoreServices.CarbonCore 0x90bd9de4 CallComponent + 260
      27 ...apple.audio.units.AudioUnit 0x94250854 AudioUnitGetPropertyInfo + 56
      28 com.apple.ecore 0x0261629c CAudioUnitRegistry::InitIOScope(ComponentInstanceRecord*, unsigned long, unsigned long, unsigned long, double, CAudioUnitRegistry::SScopeInfo&) + 112
      29 com.apple.logic.pro 0x004b14e0 0x1000 + 4916448
      30 com.apple.logic.pro 0x00109320 0x1000 + 1082144
      31 com.apple.logic.pro 0x000c06a4 0x1000 + 784036
      32 com.apple.logic.pro 0x0002ee34 0x1000 + 187956
      33 com.apple.logic.pro 0x0002f034 0x1000 + 188468
      34 com.apple.logic.pro 0x00030ba8 0x1000 + 195496
      35 com.apple.logic.pro 0x0003116c 0x1000 + 196972
      36 com.apple.logic.pro 0x0002678c 0x1000 + 153484
      37 com.apple.logic.pro 0x00036874 0x1000 + 219252
      38 com.apple.logic.pro 0x0032fc00 0x1000 + 3337216
      39 com.apple.logic.pro 0x000113a4 0x1000 + 66468
      40 com.apple.logic.pro 0x001e6e18 0x1000 + 1990168
      41 com.apple.logic.pro 0x001eecb0 0x1000 + 2022576
      42 com.apple.logic.pro 0x001eed44 0x1000 + 2022724
      43 com.apple.logic.pro 0x001e3058 0x1000 + 1974360
      44 com.apple.logic.pro 0x001e3194 0x1000 + 1974676
      45 com.apple.AE 0x914f2960 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned long, unsigned char*) + 208
      46 com.apple.AE 0x914f27fc dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 44
      47 com.apple.AE 0x914f2654 aeProcessAppleEvent + 284
      48 com.apple.HIToolbox 0x931db0e0 AEProcessAppleEvent + 60
      49 com.apple.HIToolbox 0x9321ed24 ProcessHighLevelEvent + 140
      50 com.apple.HIToolbox 0x9321ec7c StandardApplicationEventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 328
      51 com.apple.HIToolbox 0x931d7794 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 692
      52 com.apple.HIToolbox 0x931d6eec SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372
      53 com.apple.HIToolbox 0x931d6d68 SendEventToEventTargetWithOptions + 40
      54 com.apple.HIToolbox 0x931de0c8 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 704
      55 com.apple.HIToolbox 0x931d79e4 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1284
      56 com.apple.HIToolbox 0x931d6eec SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372
      57 com.apple.HIToolbox 0x931ddc8c SendEventToEventTarget + 40
      58 com.apple.HIToolbox 0x9321e9a0 ToolboxEventDispatcher + 92
      59 com.apple.HIToolbox 0x9321e92c HLTBEventDispatcher + 16
      60 com.apple.HIToolbox 0x9321cee4 RunApplicationEventLoop + 148
      61 com.apple.logic.pro 0x001e99a4 0x1000 + 2001316
      62 com.apple.logic.pro 0x0000bcd4 0x1000 + 44244
      63 com.apple.logic.pro 0x00003584 0x1000 + 9604
      64 com.apple.logic.pro 0x0000342c 0x1000 + 9260
      maybe is the clue?
      J.
    • Jun 11 2006 | 7:23 pm
      Similar situation with standalone version; but it loads about 14 instances before Max crashes.
    • Jun 11 2006 | 8:26 pm
      Okay, so the mxj wasn't responsible for the problem (I never really understood how it could be)... I had the disk buffer size argument in both sflist~ and sfplay~, which is apparently a mistake. I'm a little curious, though, about how one gets the extra outlets argument on sfplay~ without messing up the disk buffer size (since the extra outlet arg needs to follow the disk buffer size argument)?
      Does a disk buffer size argument on an sflist~ automatically override any arguments in associated sfplay~ objects? If so, I'm guessing we could use an argument of "0" in sfplay~ (thus allowing us to specify the extra outlets), but still have the desired disk buffer size assigned by sflist~. Yes? No?
      J.
    • Jun 12 2006 | 8:10 am
      On Jun 11, 2006, at 1:26 PM, jbmaxwell wrote:
      >
      > Okay, so the mxj wasn't responsible for the problem (I never really
      > understood how it could be)... I had the disk buffer size argument
      > in both sflist~ and sfplay~, which is apparently a mistake. I'm a
      > little curious, though, about how one gets the extra outlets
      > argument on sfplay~ without messing up the disk buffer size (since
      > the extra outlet arg needs to follow the disk buffer size argument)?
      >
      > Does a disk buffer size argument on an sflist~ automatically
      > override any arguments in associated sfplay~ objects? If so, I'm
      > guessing we could use an argument of "0" in sfplay~ (thus allowing
      > us to specify the extra outlets), but still have the desired disk
      > buffer size assigned by sflist~. Yes? No?
      FWIW, If you have a disk buffer argument, they must be the same for
      both sfplay~ and sflist~. If this is the case, it should work fine.
      I had thought this was in the sflist~ help file (pretty sure it was
      at some point), but it looks like it was lost somewhere along the
      way. Will add.
      -Joshua
    • Jun 12 2006 | 9:57 am
      Well, that seems the intuitive answer, and this is what I had originally done. But I was able to get more instances loaded by removing the argument from the sfplay~s, while leaving it in the sflist~. Dunno.
      Anyway, I'm now able to get about 24 instances of my patch to open before Max quits. I'll set the sfplay~s back to match the disk buffer size of sflist~ and keep messing around...
      thanks,
      J.
    • Jun 12 2006 | 11:07 am
      hmmm... if I knock down the disk buffer size my patch will load up to 32 instances. But why would this be???
      [ EDIT -- I've got 4 GB ram... and Max only shows 80 MB used in top ]
      J.
    • Jun 12 2006 | 6:14 pm
      Sounds like you're running out of memory. An example or better
      description would help us comment further (keep in mind each instance
      of sfplay~ has an internal buffer of 8x the disk buffer size and that
      each cue loads either 1x or 2x (bidirectional) the disk buffer size).
      -Joshua
    • Jun 12 2006 | 10:39 pm
      Well, it certainly does seem that way, but I don't really understand how that's possible. As I said, the total memory listed for Max in top is only around 80-90 MB when Max quits. Now I suppose I may be getting an innaccurate reading from top, but it's strange to me. Also, I was able to load up a bogus abstraction with the same general parameters, in terms of number of sfplay~s, sflist~s and disk buffer size settings. I've kind of given up for the moment; just bumped the disk buffer down until I could load as many instances as I needed. As long as performance seems okay, I'll leave it as is.
      J.