Peter Castine

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

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

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.

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]

max-crash-in-getbytes

Am 11.08.2007 um 22:24 schrieb Peter Castine:

> 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 

> 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 

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. 

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?

> 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.

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?

My problem seems to have stemmed from fiddle~.

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.

Max crash in getbytes