Remove() Tag makes Cinema crash on closin

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 29/06/2006 at 00:57, xxxxxxxx wrote:

I've found that to be a good culprit when removing elements from the document during a loop.

Crashing on exit from Cinema 4D could be a sign of a 'dangling pointer'. You are cleaning up by freeing memory at the end, but an invalid pointer was not nullified beforehand (in essence, trying to free it twice).

I'd need to see the code to find it.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 29/06/2006 at 04:56, xxxxxxxx wrote:

So one small step first.
Is Free() a part of COFFEE?.
It looks correct in the expression editor (Grey in the same way as Remove does).

However I get "member not found" whenI get to it.

  
if (userdata == 1)  
{  
tag->Remove();  
tag->Free();  
op->SetBit(BIT_AOBJ);  
return;  
}

trying
op->Free(tag);
doc->Free(op,tag);

and variation of it is the same, no member..

Cheers
Lennart

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 29/06/2006 at 05:03, xxxxxxxx wrote:

When I did that, I was keeping the general code ubiquitous.

Since this is COFFEE, there is no need to free removed document elements - the garbarge collection handles it. In this case, it may be worthwhile to NULLify any references to the removed tag so that the gc() can free the memory.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 29/06/2006 at 05:38, xxxxxxxx wrote:

To NULLify any suspected referenses is the next mission then.

Cheers
Lennart

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 29/06/2006 at 17:25, xxxxxxxx wrote:

Hm. Making a CoffeeTag plugin with -no- running code exept the loading of the icon and a UserData, Cinema still crash when quiting.
I made a Script to remove the tag to see if a Execute from somewhat "outside" would help, but no.

If I do the same thing to any other Original Tag, Cinema doesn't crash.
And as stated earlier, having the Remove() code in a ordinary COFFEE tag it works fine.

So what can the trick be? Would it be a COFFEE limitation? Is making invisible tags a way?

Cheers
Lennart

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 29/06/2006 at 17:28, xxxxxxxx wrote:

Oh, I have to add, at all times removing the Tag by deleting it manually also works fine. The thing is, the tag can be anywhere among thousands of objects in the OM (And it is always one single instance of the tag at all times). That's why I would like to have it remove itself under certain critera.

Cheers
Lennart

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 29/06/2006 at 18:05, xxxxxxxx wrote:

ooookaayy.
Here is the deal.
First taking all other plugins out, no difference.
And here it comes....this was running PPC.

Running UB it - does - not - happen!! With or without other plugins.

Close to a bug as it looks.
Will contacy Maxon tomorrow it's 3am by now and I'm dead..

Cheers
Lennart

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/06/2006 at 02:25, xxxxxxxx wrote:

Sounds like a good idea if there is a difference between PPC and UB. Post back here if you get any answers on that.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/06/2006 at 10:23, xxxxxxxx wrote:

It's late Friday so a answer will be later next week.
Meanwhile if anyone interested, especialy using Windows PC, it would be interesting to see what happens.

(The temporal) Link should be a dload of a example.

http://tca.gotdns.com/tempfiles/tagawayexamples.zip

It includes a raw TAGAWAY plugin folder and two scene examples.
One using Regular COFFEE (that works for me UB and PPC), and the other using the plugin running test ID 1000001.(UB works for me but crash Cinema PCC when quiting)

Open one of the scenes and check the "Remove" button (UserData on coffe tag and plugin tag). The Tag should dissapear.
Without doing anything else, close the scene and then quit Cinema.

Cheers
Lennart

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/06/2006 at 11:07, xxxxxxxx wrote:

The plugin tag gets removed and no crash on exit.

The COFFEE expression tag crashes Cinema 4D as soon as I hit the "Remove" button.

Windows XP Pro SP2
Cinema 4D R9.102
Cinema 4D R9.603

Now that I have the code I'll take a quick look over it - although my COFFEE experience is not up-to-par.

ETA: Although the scenes opened in R9.1 by default, I thought to check in R9.6 directly. Same situation. The COFFEE expression raised a "BugReport" dialog when the button was hit. If you would like the bugreport.txt file, I'll be glad to send it your way.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/06/2006 at 11:28, xxxxxxxx wrote:

I'm back!

One thing that I note in your code is that you aren't checking for valid pointers.

TAGAWAY::Execute(doc, op)   
{  
var ttag = op->GetFirstTag();  
if (!ttag) return;  
var remove = ttag#ID_USERDATA:1;  
  
if (remove == 0) return;  
  
if (remove == 1) ttag->Remove();  
}

My addition in RED. Now, I realize that it seems obvious that the tag should exist, but never assume a valid pointer nonetheless. Stranger things have happened.

Also, there is a chance that someone has placed a tag before yours, so you should loop through the object's tag list, checking for your plugintag class using instanceOf(). The COFFEE Expression tag may be a little more difficult here.

The COFFEE Expression tag might be more treacherous. Having code in the tag to remove that tag may not be legal or cause some sort of referential problem (the code may expect the tag to exist after execution of the script as it calls some internal process - I don't know). I'll leave this to someone with more experience with such matters.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/06/2006 at 12:04, xxxxxxxx wrote:

Many thanks for looking at it Robert!
First, if I got it right, it looks as if you get crashes the other way around:)
(Regular COFFEE crash, and "My" plug is "safe")

As for checking if tag exists, I run a tag check in the full code, so it shouldn't be the problem.
To "proof" that (I think) , try emty the code in the plugin so it does nothing then put this in script manager and delete it that way.
I do get the same crash...
(Replace "Tcoffeeexpression" with "1019902" for checking my plug)

  
var ttag= op->GetFirstTag();  
if (ttag->IsInstanceOf(Tcoffeeexpression))   
  
doc->StartUndo();  
{  
doc->AddUndo(UNDO_TAG_DEL,ttag);  
ttag->Remove();  
op->Message(MSG_UPDATE);  
}  
  
doc->EndUndo();

As for the crash report it would be nice to have, not that I might be able to understand it, but Maxon might hopefully.

I'm at:

tca AT telia DOT com

Cheers
Lennart

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/06/2006 at 14:28, xxxxxxxx wrote:

You made it easy to check.

Yes, that was my thought as well. On Windows, the crash is the COFFEE Expression tag directly and no crash on the plugin tag - but you say you have no crash with the COFFEE tag and a crash on exit with the plugin tag on MacOS.

Ah, so this was just a quick test code then. Sorry for getting too critical.

Now, the question that must be asked. Why do you need your tag to remove itself? Is it not just as easy for a user to delete it or is there some automation going on where you set the "Remove" checkbox from some other process? Just curious.

I believe that your email address is already in my contacts. Yeah, most of the information in the bugreport.txt is basic crash dump, but, as you say, Maxon might make sense of it.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/06/2006 at 14:54, xxxxxxxx wrote:

Thanks Robert.
Yea, our crashes are inverted..
And the answer that must be answered is:
Yes its a process (that works fine) that when it is finished should get rid of this tag. Since it is save (you might check that as well, come to think of it:) )
to delete the tag manually, I have a temporal solution using a script that finds the tag so it could be deleted the normal way.
The process -could- make it hard to find the tag, so that's why really
A workflow matter.

Cheers
Lennart

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/06/2006 at 14:58, xxxxxxxx wrote:

Oh darn!
I just saw that I said to use ID 10109902. It should of coarse be:
ID 1000001 (The test ID)!

That might make a difference on your end.

Cheers
Lennart

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/06/2006 at 16:21, xxxxxxxx wrote:

Noted the change of ID.

Now, in my (not very popular) Drop It! Pro plugin (I know that you are a user - thank you), 'target' and 'source' tags are added when the drop is a collision between objects. In the settings for this, the user can opt to have these tags removed after processing. But this removal is strictly done by the main plugin (Commmand plugin) and not the tags themselves.

I take it that the processing is done within the tags and, therefore, the removal is there as well - in a general sense and meaning that there is no other 'plugin' governing the process as in my case. The problem here seems to be how to have a tag remove itself without adverse consequences - no matter how varied the response. It appears that at some point, the removal process is allowing some sort of situation to occur that leaves the tag unable to go away quietly.

If you could send the full code, I'd be happy to see if I can find the problem with some trials. There is no worry about stealing as I'm up to my eye-balls in beta-testing. My main focus is interPoser Pro - no desires to take credit for someone else's hard work. But it is nice to have an alternate focus once in a while to ease the tribulations of the work at hand if you know what I mean.