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…

Olaf

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?

jb

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
> use?

Hi Jeremy,

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);
}
}

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

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.

Olaf

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

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

-Joshua

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

-Joshua