Olaf Matthes

While everybody is waiting for the Max5 SDK I have a question I always 

wanted to ask about the Max 4.6 SDK (I mean the latest one on the website):

I was working on an external using the obex API that opens an invisible 

'sub class' as shown in the myregob code (which creates several 

minimetro classes). All is fine with opening and using these classes, i 

can even call object_free() once but as soon as I call it the second 

This happens either if one object has several sub classes it wants to 

free or when I have two instances of the same object with just one 

First I thought this would just happen to me, but recently other people 

reported the same problem with my external. The same code works fine on Mac.

Attached is the myregob object compiled straight from the SDK using MS 

Visual Studio 2003. If I put several [myregob 100] in one patch, for 

example, it crashes when I remove the second one from the patch. With 

[myregob 100 200] it happens right after removing the first one. So it 

seems it always crashes when object_free() is called on the same class 

Is this a compiler issue? Or something else I'm doing wrong?

While everybody is waiting for the Max5 SDK I have a question I always 
wanted to ask about the Max 4.6 SDK (I mean the latest one on the website):

I was working on an external using the obex API that opens an invisible 
'sub class' as shown in the myregob code (which creates several 
minimetro classes). All is fine with opening and using these classes, i 
can even call object_free() once but as soon as I call it the second 
time Max crashes.
This happens either if one object has several sub classes it wants to 
free or when I have two instances of the same object with just one 
subclass each.
First I thought this would just happen to me, but recently other people 
reported the same problem with my external. The same code works fine on Mac.

Attached is the myregob object compiled straight from the SDK using MS 
Visual Studio 2003. If I put several [myregob 100] in one patch, for 
example, it crashes when I remove the second one from the patch. With 
[myregob 100 200] it happens right after removing the first one. So it 
seems it always crashes when object_free() is called on the same class 
for the second time.

obex-api-crashes-windows

Just to give it some importance: it also happens in Max5. (I know there 

will be a Max5 SDK but still, there is a something wrong with the Max 4 

SKD and it would be great if I could use object_free() for my Max4 

> While everybody is waiting for the Max5 SDK I have a question I always 

> wanted to ask about the Max 4.6 SDK (I mean the latest one on the website):

> I was working on an external using the obex API that opens an invisible 

> 'sub class' as shown in the myregob code (which creates several 

> minimetro classes). All is fine with opening and using these classes, i 

> can even call object_free() once but as soon as I call it the second 

> This happens either if one object has several sub classes it wants to 

> free or when I have two instances of the same object with just one 

> First I thought this would just happen to me, but recently other people 

> reported the same problem with my external. The same code works fine on 

> Attached is the myregob object compiled straight from the SDK using MS 

> Visual Studio 2003. If I put several [myregob 100] in one patch, for 

> example, it crashes when I remove the second one from the patch. With 

> [myregob 100 200] it happens right after removing the first one. So it 

> seems it always crashes when object_free() is called on the same class 

> Is this a compiler issue? Or something else I'm doing wrong?

> ------------------------------------------------------------------------

Just to give it some importance: it also happens in Max5.  (I know there 
will be a Max5 SDK but still, there is a something wrong with the Max 4 
SKD and it would be great if I could use object_free() for my Max4 
externals).

Olaf Matthes wrote:
> While everybody is waiting for the Max5 SDK I have a question I always 
> wanted to ask about the Max 4.6 SDK (I mean the latest one on the website):
>
> I was working on an external using the obex API that opens an invisible 
> 'sub class' as shown in the myregob code (which creates several 
> minimetro classes). All is fine with opening and using these classes, i 
> can even call object_free() once but as soon as I call it the second 
> time Max crashes.
> This happens either if one object has several sub classes it wants to 
> free or when I have two instances of the same object with just one 
> subclass each.
> First I thought this would just happen to me, but recently other people 
> reported the same problem with my external. The same code works fine on 
> Mac.
>
> Attached is the myregob object compiled straight from the SDK using MS 
> Visual Studio 2003. If I put several [myregob 100] in one patch, for 
> example, it crashes when I remove the second one from the patch. With 
> [myregob 100 200] it happens right after removing the first one. So it 
> seems it always crashes when object_free() is called on the same class 
> for the second time.
>
> Is this a compiler issue? Or something else I'm doing wrong?
>
> Olaf
>
>
> ------------------------------------------------------------------------
>


On Oct 27, 2008, at 8:22 AM, Olaf Matthes wrote:

> Just to give it some importance: it also happens in Max5. (I know 

> there will be a Max5 SDK but still, there is a something wrong with 

> the Max 4 SKD and it would be great if I could use object_free() for 

This sounds like there's some issue with your classes, since this has 

worked fine in our objects for a long time. If you repost the source 

of the problem externals, perhaps we could suggest what is the issue. 

Things to watch out for in your free method:

- freeing memory allocated in different memory pool (e.g. getbytes vs. 

- freeing pointers which have been trashed by memory overrun

- freeing your own object struct, rather than letting it be freed by 

- freeing something which has not been allocated with object_alloc

Otherwise, it sounds like a more general memory corruption issue.

> Just to give it some importance: it also happens in Max5.  (I know  
> there will be a Max5 SDK but still, there is a something wrong with  
> the Max 4 SKD and it would be great if I could use object_free() for  
> my Max4 externals).

This sounds like there's some issue with your classes, since this has  
worked fine in our objects for a long time. If you repost the source  
of the problem externals, perhaps we could suggest what is the issue.  
Things to watch out for in your free method:

- freeing uninitialized pointer values
- freeing memory allocated in different memory pool (e.g. getbytes vs.  
sysmem_newptr vs. malloc)
- freeing pointers which have been trashed by memory overrun
- freeing your own object struct, rather than letting it be freed by  
object_free
- freeing something which has not been allocated with object_alloc

> On Oct 27, 2008, at 8:22 AM, Olaf Matthes wrote:

>> Just to give it some importance: it also happens in Max5. (I know 

>> there will be a Max5 SDK but still, there is a something wrong with 

>> the Max 4 SKD and it would be great if I could use object_free() for 

> This sounds like there's some issue with your classes, since this has 

> worked fine in our objects for a long time. If you repost the source of 

> the problem externals, perhaps we could suggest what is the issue.

the source is straight from the SDK: myregob.c

I had the compiled binary attached to my initial message.

Joshua Kit Clayton wrote:
>
> On Oct 27, 2008, at 8:22 AM, Olaf Matthes wrote:
>
>> Just to give it some importance: it also happens in Max5.  (I know 
>> there will be a Max5 SDK but still, there is a something wrong with 
>> the Max 4 SKD and it would be great if I could use object_free() for 
>> my Max4 externals).
>
> This sounds like there's some issue with your classes, since this has 
> worked fine in our objects for a long time. If you repost the source of 
> the problem externals, perhaps we could suggest what is the issue. 

the source is straight from the SDK: myregob.c
I had the compiled binary attached to my initial message.

On Oct 27, 2008, at 9:13 AM, Olaf Matthes wrote:

> the source is straight from the SDK: myregob.c

> I had the compiled binary attached to my initial message.

Thanks. I think there's something wrong in Jeremy's example. I'll let 

him investigate further, but on cursory examination, I believe it's 

not a great idea to unregister within the free notification (since 

when notifying, one is relying on the registration data structures). 

It's actually unnecessary to even unregister in this case, since when 

an object is freed, it also unregisters itself. However, if one is 

going to unregister an object, it should be done before calling 

object_free rather than within a notification about it. Sorry for any 

confusion. object_free itself should be fine.

Let us know if commenting out (or moving from the notification to the 

myregob_free method) the following lines:

object_detach(gensym("_regob_test"), s, x);

> the source is straight from the SDK: myregob.c
> I had the compiled binary attached to my initial message.

Thanks. I think there's something wrong in Jeremy's example. I'll let  
him investigate further, but on cursory examination, I believe it's  
not a great idea to unregister within the free notification (since  
when notifying, one is relying on the registration data structures).  
It's actually unnecessary to even unregister in this case, since when  
an object is freed, it also unregisters itself. However, if one is  
going to unregister an object, it should be done before calling  
object_free rather than within a notification about it. Sorry for any  
confusion. object_free itself should be fine.

Let us know if commenting out (or moving from the notification to the  
myregob_free method) the following lines:

object_detach(gensym("_regob_test"), s, x);
object_unregister(sender);

> Thanks. I think there's something wrong in Jeremy's example. I'll let 

> him investigate further, but on cursory examination, I believe it's not 

> a great idea to unregister within the free notification (since when 

> notifying, one is relying on the registration data structures). It's 

> actually unnecessary to even unregister in this case, since when an 

> object is freed, it also unregisters itself. However, if one is going to 

> unregister an object, it should be done before calling object_free 

> rather than within a notification about it. Sorry for any confusion. 

> Let us know if commenting out (or moving from the notification to the 

> myregob_free method) the following lines:

> object_detach(gensym("_regob_test"), s, x);

Tried to comment them out, but the problem persists.

Also, the same code seems to work on OS X without trouble.

Joshua Kit Clayton wrote:
> Thanks. I think there's something wrong in Jeremy's example. I'll let 
> him investigate further, but on cursory examination, I believe it's not 
> a great idea to unregister within the free notification (since when 
> notifying, one is relying on the registration data structures). It's 
> actually unnecessary to even unregister in this case, since when an 
> object is freed, it also unregisters itself. However, if one is going to 
> unregister an object, it should be done before calling object_free 
> rather than within a notification about it. Sorry for any confusion. 
> object_free itself should be fine.
>
> Let us know if commenting out (or moving from the notification to the 
> myregob_free method) the following lines:
>
> object_detach(gensym("_regob_test"), s, x);
> object_unregister(sender);

Tried to comment them out, but the problem persists.
Also, the same code seems to work on OS X without trouble.

The issue is that the project has a typo so that x->mmo is being freed

twice in myregob_free. Please make the following change:

// changed following line from double freeing x->mmo to correctly freeing

    freebytes(x->proxy, sizeof(void *) * x->count);

Please let us know if you find other problems.

The issue is that the project has a typo so that x->mmo is being freed
twice in myregob_free. Please make the following change:

if (x->proxy) {
	for (i = 1; i < x->count; i++) {
		freeobject(x->proxy[i]);
	}
// changed following line from double freeing x->mmo to correctly freeing
x->proxy
	freebytes(x->proxy, sizeof(void *) * x->count);
}

> The issue is that the project has a typo so that x->mmo is being freed

And sorry for neglecting to mention that this change *and* the removal of

the incorrect unregistration in free notification are both required.

> The issue is that the project has a typo so that x->mmo is being freed
> twice in myregob_free.

And sorry for neglecting to mention that this change *and* the removal of
the incorrect unregistration in free notification are both required.

> twice in myregob_free. Please make the following change:

>     for (i = 1; i < x->count; i++) {

>         freeobject(x->proxy[i]);

> // changed following line from double freeing x->mmo to correctly freeing

>     freebytes(x->proxy, sizeof(void *) * x->count);

> Please let us know if you find other problems.

that solved my problem. Actually, the real problem was the 

object_detach() and object_unregister() in the notification. Since 

myregob is the only example showing that feature I always did it like 

Due to the double free it was still crashing in the case of myregob.

So now I can finally continue on working on the next flashserver version 

which will instantiate a separate object for each connected Flash client.

Joshua Kit Clayton wrote:
> Hi Olaf,
>
> The issue is that the project has a typo so that x->mmo is being freed
> twice in myregob_free. Please make the following change:
>
> if (x->proxy) {
> 	for (i = 1; i < x->count; i++) {
> 		freeobject(x->proxy[i]);
> 	}
> // changed following line from double freeing x->mmo to correctly freeing
> x->proxy
> 	freebytes(x->proxy, sizeof(void *) * x->count);
> }
>
> Please let us know if you find other problems.

that solved my problem. Actually, the real problem was the 
object_detach() and object_unregister() in the notification. Since 
myregob is the only example showing that feature I always did it like 
that in my externals.
Due to the double free it was still crashing in the case of myregob.
So now I can finally continue on working on the next flashserver version 
which will instantiate a separate object for each connected Flash client.

Thanks. I'm away from my desk for a few weeks right now, battling sharks with a vast assortment of exotic fruits... I'll take a look when I get back to civilization.

obex API crashes (Windows)