While working on a large patch, the following sequence crashes Max pretty reliably: close patch, re-open, crash. The crash is always in getbytes(), with a log as follows

Thread 0 Crashed:
0 com.cycling74.MaxMSP46 0x00067c8f memoryheap_getbytes(_memoryheap*, short) + 171 (utilities.c:260)
1 com.cycling74.MaxMSP46 0x00067e2c getbytes + 42 (utilities.c:232)
2 com.cycling74.MaxAPI 0x01809b02 getbytes + 38
3 com.cycling74.zl 0x16e95e8d zl_new + 126
[schnipp]

I don’t actually believe that zl is buggy, but suspect that some object is incorrectly deallocating memory when I close my patch.

The culprit could be anywhere in 500MB in subpatches using about 200 externals. Even a binary search is going to be pretty tedious. Does anyone have suggestions for tracking down getbytes/freebytes misbehavior more efficiently. I have the Apple developer tools installed.

I’d be happy to send a complete crash log, but if I’m right and the real problem is occurring microseconds before the crash, then it’s probably moot.

Thanks for any ideas,

P.

> I don’t actually believe that zl is buggy, but suspect that some
> object is incorrectly deallocating memory when I close my patch.
>
> The culprit could be anywhere in 500MB in subpatches using about
> 200 externals. Even a binary search is going to be pretty tedious.
> Does anyone have suggestions for tracking down getbytes/freebytes
> misbehavior more efficiently. I have the Apple developer tools
> installed.
>
> I’d be happy to send a complete crash log, but if I’m right and the
> real problem is occurring microseconds before the crash, then it’s
> probably moot.

Hi Peter,

I have run into similar things before. This crashlog usually
indicates that there is a memory leak somewhere in on of the
externals being used, usually not the one that is actually crashing.
But this is what you already gussed.
The only solution I know of is stripping down the patch be removing
one third-party external after the other until the problem goes away.
But since removing externals will render parts of the pach non-
functional this will not necesserrally tell you who is the culprit.
One thing that might help is observing when the crash happens. Since
you say it happens when you reload a previously opened patch I would
guess there is an external not freeing it’s memory correctly or at
least not doeing it’s cleanup in the right way. So maybe just
reopening each help patch for all the externals you use tells you
which external doesn’t like to be reloaded?

Olaf

To be precise: several fiddle~ objects without explicit initialization arguments.

Simply instantiating [fiddle~] w/out arguments used to do what one would expect: silently use sensible defaults. But at some stage (v1.2?) I started getting non-silent correction (ie, error messages about invalid npoint) and since updating to Max/MSP 4.6.3 I started getting the crash behavior described previously. Using an explicit first argument, as in [fiddle~ 1024] seems to solve the problem.

Who is actually maintaining the MSP version of fiddle~ nowadays? I would just like to send whomever a heads-up about the issue.