Olaf Matthes

the WritingExternals PDF states that when using defer() and defer_low 

"argv - Array containing a variable number of function

arguments. If this argument is non-zero, defer

allocates memory to make a copy of the arguments

(according to the size passed in argc) and passes the

copied array to the function fun when it executes as

Since I'm getting some strange crashes on OS X 10.4.8 with Max 4.6.2 

I was wondering whether I have to manually free this memory in the 

function that gets called by defer()? And if so, which one of the 

memory freeing routines (freebytes() or sysmem_freeptr()) to use?

And another question related to the sysmem API: I'm currently working 

on a rather simple external (simple in terms of memory allocations) 

and changed it from getbyte()s function to sysmem_newptr() (of 

course, I changed all the memory allocation / freeing / resizing 

functions accordingly). Surprisingly I get now Max crashes with the 

very same code. There is no way to say when it crashes, but it will 

crash sooner or later when I send my external a message that calles 

one of the sysmem functions. The crashlog usually says something like 

0 libSystem.B.dylib     0x90002aa6 szone_malloc + 308

1 libSystem.B.dylib     0x9000268f malloc + 597

2 ...ple.CoreServices.CarbonCore     0x90c9c23a CSMemNewPtr + 39

3 ...ple.CoreServices.CarbonCore     0x90ca0458 NewPtr + 29

4 com.cycling74.MaxMSP46     0x00061a43 sysmem_resizeptr + 17 

5 com.cycling74.MaxAPI     0x0180c31e sysmem_resizeptr + 37

6 com.cycling74.at.oracle     0x159c82e4 

7 com.cycling74.at.oracle     0x159c87a1 ftmoracle_int + 234

8 com.cycling74.MaxMSP46     0x000e6de3 outlet_int + 361 

What do I learn from this report? It's crashing in libSystem when 

This time there are no threads involved in my external...

the WritingExternals PDF states that when using defer() and defer_low 
() the following applies:

"argv - Array containing a variable number of function
arguments. If this argument is non-zero, defer
allocates memory to make a copy of the arguments
(according to the size passed in argc) and passes the
copied array to the function fun when it executes as
the fourth argument."

Since I'm getting some strange crashes on OS X 10.4.8 with Max 4.6.2  
I was wondering whether I have to manually free this memory in the  
function that gets called by defer()? And if so, which one of the  
memory freeing routines (freebytes() or sysmem_freeptr()) to use?

And another question related to the sysmem API: I'm currently working  
on a rather simple external (simple in terms of memory allocations)  
and changed it from getbyte()s function to sysmem_newptr() (of  
course, I changed all the memory allocation / freeing / resizing  
functions accordingly). Surprisingly I get now Max crashes with the  
very same code. There is no way to say when it crashes, but it will  
crash sooner or later when I send my external a message that calles  
one of the sysmem functions. The crashlog usually says something like  
this:

Thread 0 Crashed:
0   libSystem.B.dylib              	0x90002aa6 szone_malloc + 308
1   libSystem.B.dylib              	0x9000268f malloc + 597
2   ...ple.CoreServices.CarbonCore 	0x90c9c23a CSMemNewPtr + 39
3   ...ple.CoreServices.CarbonCore 	0x90ca0458 NewPtr + 29
4   com.cycling74.MaxMSP46         	0x00061a43 sysmem_resizeptr + 17  
(sysmem.c:63)
5   com.cycling74.MaxAPI           	0x0180c31e sysmem_resizeptr + 37
6   com.cycling74.at.oracle        	0x159c82e4  
ftmoracle_oracle_add_trans + 117
7   com.cycling74.at.oracle        	0x159c87a1 ftmoracle_int + 234
8   com.cycling74.MaxMSP46         	0x000e6de3 outlet_int + 361  
(inletoutlet.c:753)

What do I learn from this report? It's crashing in libSystem when  
allocating (resizing) memory???
This time there are no threads involved in my external...

defer-and-memory-allocation-sysmem

No, you don't need to do anything, or know anything, about this 

As for your crash, yes, it's happening during a memory reallocation. 

How much memory are you trying to allocate? Could you maybe share 

some code so that we can see what you are working with?

Am 03.04.2007 um 18:38 schrieb Olaf Matthes:

> Since I'm getting some strange crashes on OS X 10.4.8 with Max 

> 4.6.2 I was wondering whether I have to manually free this memory 

> in the function that gets called by defer()? And if so, which one 

> of the memory freeing routines (freebytes() or sysmem_freeptr()) to 

No, you don't need to do anything, or know anything, about this  
memory. It belongs to the Max kernel.

As for your crash, yes, it's happening during a memory reallocation.  
How much memory are you trying to allocate? Could you maybe share  
some code so that we can see what you are working with?

> Since I'm getting some strange crashes on OS X 10.4.8 with Max  
> 4.6.2 I was wondering whether I have to manually free this memory  
> in the function that gets called by defer()? And if so, which one  
> of the memory freeing routines (freebytes() or sysmem_freeptr()) to  
> use?


> No, you don't need to do anything, or know anything, about this memory. 

> As for your crash, yes, it's happening during a memory reallocation. How 

> much memory are you trying to allocate? Could you maybe share some code 

> so that we can see what you are working with?

thanks for the input regarding defer_low(). It turned our my 

sysmem_resizebytes() problem was related to that: in the allocated 

memory I tried to resize I was storing pointers to symbols that were 

passed trough a defer()ed function (as list of t_atoms of type A_SYM) 

and thus probably 'disappeared' while I was still trying to access them. 

After allocating memory for them at the new location and storing a copy 

instead of a pointer everything works fine now.

One thing I realised after figuring that out is that some code that 

Joshua once send me for thread-safe printing is also wrong. Here's what 

static void post_dostring(t_myobject *x, char *p)

static void threadsafe_post(t_myobject *x, char *p)

    if((q = sysmem_newptr(strlen(p))))

        defer(x, (method)post_dostring, (t_symbol *)q, 0, 0L);

But at closer look the second function should look like this:

    if((q = sysmem_newptr(strlen(p) + 1)))

First we have to alloc strlen(p) + 1 and not just strlen(p) bytes 

because of the null termination of the incoming string. Second issue is 

to make a copy of the string p and not just have q point to it.

This is not really conncted to defer_low() but falls into the same 

category of assuming that pointing to something is safe. Usually it's not.

Jeremy Bernstein wrote:
> No, you don't need to do anything, or know anything, about this memory. 
> It belongs to the Max kernel.
>
> As for your crash, yes, it's happening during a memory reallocation. How 
> much memory are you trying to allocate? Could you maybe share some code 
> so that we can see what you are working with?

thanks for the input regarding defer_low(). It turned our my 
sysmem_resizebytes() problem was related to that: in the allocated 
memory I tried to resize I was storing pointers to symbols that were 
passed trough a defer()ed function (as list of t_atoms of type A_SYM) 
and thus probably 'disappeared' while I was still trying to access them. 
After allocating memory for them at the new location and storing a copy 
instead of a pointer everything works fine now.

One thing I realised after figuring that out is that some code that 
Joshua once send me for thread-safe printing is also wrong. Here's what 
he suggested to use:

static void post_dostring(t_myobject *x, char *p)
{
     post("%s: %s", ob_sym(x)->s_name, p);
     sysmem_freeptr(p);
}

static void threadsafe_post(t_myobject *x, char *p)
{
	char *q;
	if((q = sysmem_newptr(strlen(p))))
	{
		q = p;
		defer(x, (method)post_dostring, (t_symbol *)q, 0, 0L);
	}
}

static void threadsafe_post(t_myobject *x, char *p)
{
	char *q;
	if((q = sysmem_newptr(strlen(p) + 1)))
	{
		strcpy(q, p);
		defer(x, (method)post_dostring, (t_symbol *)q, 0, 0L);
	}
}

First we have to alloc strlen(p) + 1 and not just strlen(p) bytes 
because of the null termination of the incoming string. Second issue is 
to make a copy of the string p and not just have q point to it.
This is not really conncted to defer_low() but falls into the same 
category of assuming that pointing to something is safe. Usually it's not.

FWIW, here's the message I tried to send you, but it didn't seem to 

On Apr 3, 2007, at 9:38 AM, Olaf Matthes wrote:

Defer frees the memory after calling into your function. Therefore 

you need to copy this data again to your own memory if you want to 

retain reference to this information. Also, you cannot resize this 

> And another question related to the sysmem API: I'm currently 

> working on a rather simple external (simple in terms of memory 

> allocations) and changed it from getbyte()s function to 

> sysmem_newptr() (of course, I changed all the memory allocation / 

> freeing / resizing functions accordingly). Surprisingly I get now 

> Max crashes with the very same code. There is no way to say when it 

> crashes, but it will crash sooner or later when I send my external 

> a message that calles one of the sysmem functions. The crashlog 

> 0 libSystem.B.dylib     0x90002aa6 szone_malloc + 308

If you're passing in valid sysmem (and not getbytes or some other) 

pointers, this just means memory has been corrupted. Probably happens 

shortly before your memory reallocation. These sorts of bugs can be 

tricky to track down. You'll want to look at all your memory 

allocation and accessing code (make sure you're not assuming 

uninitialized pointers will be NULL). If you're trying to access the 

memory passed in from defer beyond the extents of your callback, you 

would see these types of crashes, but it could be something else.

FWIW, here's the message I tried to send you, but it didn't seem to  
go through given the server issues.

> Since I'm getting some strange crashes on OS X 10.4.8 with Max  
> 4.6.2 I was wondering whether I have to manually free this memory  
> in the function that gets called by defer()? And if so, which one  
> of the memory freeing routines (freebytes() or sysmem_freeptr()) to  
> use?
>

Defer frees the memory after calling into your function. Therefore  
you need to copy this data again to your own memory if you want to  
retain reference to this information. Also, you cannot resize this  
memory.

> And another question related to the sysmem API: I'm currently  
> working on a rather simple external (simple in terms of memory  
> allocations) and changed it from getbyte()s function to  
> sysmem_newptr() (of course, I changed all the memory allocation /  
> freeing / resizing functions accordingly). Surprisingly I get now  
> Max crashes with the very same code. There is no way to say when it  
> crashes, but it will crash sooner or later when I send my external  
> a message that calles one of the sysmem functions. The crashlog  
> usually says something like this:
>
> Thread 0 Crashed:
> 0   libSystem.B.dylib              	0x90002aa6 szone_malloc + 308
>

If you're passing in valid sysmem (and not getbytes or some other)  
pointers, this just means memory has been corrupted. Probably happens  
shortly before your memory reallocation. These sorts of bugs can be  
tricky to track down. You'll want to look at all your memory  
allocation and accessing code (make sure you're not assuming  
uninitialized pointers will be NULL). If you're trying to access the  
memory passed in from defer beyond the extents of your callback, you  
would see these types of crashes, but it could be something else.

On Apr 6, 2007, at 10:02 AM, Olaf Matthes wrote:

> One thing I realised after figuring that out is that some code that 

> Joshua once send me for thread-safe printing is also wrong.

> First we have to alloc strlen(p) + 1 and not just strlen(p) bytes 

> because of the null termination of the incoming string. Second 

> issue is to make a copy of the string p and not just have q point 

You are totally correct. Sorry or the ill guided quick email client 

>
> One thing I realised after figuring that out is that some code that  
> Joshua once send me for thread-safe printing is also wrong.
> First we have to alloc strlen(p) + 1 and not just strlen(p) bytes  
> because of the null termination of the incoming string. Second  
> issue is to make a copy of the string p and not just have q point  
> to it.

You are totally correct. Sorry or the ill guided quick email client  
coding.

defer() and memory allocation / sysmem