strange

Jun 9, 2006 at 10:11am

strange

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.

#26351
Jun 9, 2006 at 10:43pm

Are you doing any swing stuff? Are you on OS X?
topher

#78673
Jun 10, 2006 at 8:07am

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.

#78674
Jun 10, 2006 at 12:51pm

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.

#78675
Jun 10, 2006 at 1:24pm

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.

#78676
Jun 11, 2006 at 11:11am

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.

#78677
Jun 11, 2006 at 12:09pm

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 (0×0001)
Codes: KERN_PROTECTION_FAILURE (0×0002) 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 0×27252840 xpcoll_findload + 44
14 MaxPPC3.1 0×27247940 linklist_funall + 80
15 MaxPPC3.1 0×27252734 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 0×94250854 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 0×1000 + 4916448
30 com.apple.logic.pro 0×00109320 0×1000 + 1082144
31 com.apple.logic.pro 0x000c06a4 0×1000 + 784036
32 com.apple.logic.pro 0x0002ee34 0×1000 + 187956
33 com.apple.logic.pro 0x0002f034 0×1000 + 188468
34 com.apple.logic.pro 0x00030ba8 0×1000 + 195496
35 com.apple.logic.pro 0x0003116c 0×1000 + 196972
36 com.apple.logic.pro 0x0002678c 0×1000 + 153484
37 com.apple.logic.pro 0×00036874 0×1000 + 219252
38 com.apple.logic.pro 0x0032fc00 0×1000 + 3337216
39 com.apple.logic.pro 0x000113a4 0×1000 + 66468
40 com.apple.logic.pro 0x001e6e18 0×1000 + 1990168
41 com.apple.logic.pro 0x001eecb0 0×1000 + 2022576
42 com.apple.logic.pro 0x001eed44 0×1000 + 2022724
43 com.apple.logic.pro 0x001e3058 0×1000 + 1974360
44 com.apple.logic.pro 0x001e3194 0×1000 + 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 0×1000 + 2001316
62 com.apple.logic.pro 0x0000bcd4 0×1000 + 44244
63 com.apple.logic.pro 0×00003584 0×1000 + 9604
64 com.apple.logic.pro 0x0000342c 0×1000 + 9260

maybe is the clue?

J.

#78678
Jun 11, 2006 at 7:23pm

Similar situation with standalone version; but it loads about 14 instances before Max crashes.

#78679
Jun 11, 2006 at 8:26pm

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.

#78680
Jun 12, 2006 at 8:10am

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

#78681
Jun 12, 2006 at 9:57am

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.

#78682
Jun 12, 2006 at 11:07am

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.

#78683
Jun 12, 2006 at 6:14pm

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

#78684
Jun 12, 2006 at 10:39pm

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.

#78685

You must be logged in to reply to this topic.