Identify Critical Stop Please?

kvb

Anyone ever come across this... or a dev with direct access to the info care to shed light on this? I was just doing some final testing before sending this thing off and finally getting the code out of my head when this popped up:

Critical: Stop [ge_container.h(277)]

I know it means I'm accessing data in a base container incorrectly. But not knowing what kind (and lacking a proper debugger in python) it's becoming a real pain to reproduce and track this down. If I knew the data type in question it would certainly help narrow it down. I know from some threads here on the forum that if the error referenced line 247 it was a vector, and 329 is a baselink. Unfortunately, no one's come along with an error referencing line 277, so here I am:)

Thanks!
Kevin

ferdinand

Hi,

@kvb said in Identify Critical Stop Please?:

when this popped up

this is rather vague, but I'll assume you are referring to an exception in the console and not a to a crash report. Which would mean that there should be a full traceback and not just the error. You should:

provide the full traceback
provide the code related to the items in the traceback stack
test the state of your variables when the exception occurs (which can be difficult in Cinema / become quite a print-fest)

If your problem is BaseContainer related, the only advice I can think off, is to use the dedicated type related setters and getters and not the convince methods __getitem__ and __setitem__, because the Python types cannot always be mapped unambiguously to the correct DTYPE.

Cheers,
zipit

kvb

Hey,
Yeah, it is a bit vague, but that's because the only people who could possibly answer would know exactly what that is without any context behind it. It is in the crash report, btw, not the console, and other than a timestamp, this is the complete error code.
Some examples of others encountering similar problems:
https://developers.maxon.net/forum/topic/9850/13264_cinema-crashed-when-selecting-gradient
https://developers.maxon.net/forum/topic/10339/13832_debugger-critical-stop-

Yes, I'm properly initializing my attributes with the proper datatypes and getting/setting them in the appropriate fashion... though I may be missing one somewhere. I'll have to continue to scour my code... but knowing what this particular critical stop is referring to (like those other threads I linked) would be very helpful.

Thanks!

Manuel

hello,

For your next threads, please help us keeping things organised and clean. I know it's not your priority but it really simplify our work here.

Q&A New Functionality.

About the error it's related to FileName. But we need more information to help more.
Be careful about the other thread, it may happen that we add stuff and the line will not refer to the correct DataType anymore.

Cheers,
Manuel

r_gigante

Hi @kvb, with regard to the scope and purpose of the CriticalStop I warmly recommend you to have a look at:

These pages properly explain how the CriticalStop is used in Cinema 4D, how it can be used in plugins and what to expect when it's hit.

In you case, as already pointed out by @m_magalhaes , it's likely you're using a GeData::GetFilename() with a GeData whose type was not a Filename. Please recheck your code and if you don't spot the issue, provide us with an example or snippet to reproduce it.

Cheers, R

kvb

@m_magalhaes said in Identify Critical Stop Please?:

hello,

For your next threads, please help us keeping things organised and clean. I know it's not your priority but it really simplify our work here.

Q&A New Functionality.

About the error it's related to FileName. But we need more information to help more.
Be careful about the other thread, it may happen that we add stuff and the line will not refer to the correct DataType anymore.

Cheers,
Manuel

Dammit! No wonder my code keeps breaking... I can't even follow simple forum instructions lol! But hey, at least I got it down to one link. Haha, progress!

Yes, Filename, that actually makes perfect sense, so I'm pretty confident I've conquered this error. You're right that I shouldn't rely too strongly on those line numbers. Hell, the next bug fix could make that info obsolete, let alone a reference from years ago. But sometimes you can glean value from outdated info. Maybe in the future line 277 doesn't refer to Filename, but if that error pops up and all my Filename calls look to be in good order I might be able to make some guesses that increase my luck in identifying the issue faster. For instance, I might look at string or static text parameters first, thinking that like datatypes may have been grouped together in the source code. If 329 doesn't refer to baselink in the future I might start looking at in/exclude boxes or shader links first for the same reason. Maybe the list of datatypes in the description manual in the sdk is ordered how they are in ge_container.h and I can use that to choose my next lead. Shot in the dark type stuff, for sure, but maybe gets me generally in the right direction.

You know what, this may have to do with me tracking down a weird behavior where Init() seemed to be the cause of every parameter invoking a MSG_DESCRIPTION_POSTSETPARAMETER message on any parameter change... but I have both debugging AND pandemic fog on my brain, so I don't even know exactly which thing I was doing wrong that may have been the culprit, so there's no point getting into all that... doesn't help that a VS Code update seems to like breaking my local git repo's randomly, so that makes reviewing previous code fun. In any case, the error hasn't popped up at all after ensuring all my base container calls were proper and there were no missing parameter initializations. Not that it was a readily reproduce-able error, just one that would pop up sometimes after a heavy testing session... so I had to do a lot of those to ensure it's really gone.

But it does raise a question. Since the Filename object doesn't exist in python, what's the best way to initialize it? Docs say it's a string, but I saw something in a forum post that someone was initializing their filename parameter directly through the base container. I figured this had to do with how the python wrapper is internally converting the path to Filename object or something, so that's what I've been doing, but that WAS from 2013. So which is the proper way to initialize it?

self.InitAttr(node, str, c4d.ID_FILENAME_PARAMETER)

or

data.SetFilename(c4d.ID_FILENAME_PARAMETER, "")

And even if it's the former, do I set its default value through the basecontainer or in the normal way like so:

node[c4d.ID_FILENAME_PARAMETER] = ""

@r_gigante said in Identify Critical Stop Please?:

Hi @kvb, with regard to the scope and purpose of the CriticalStop I warmly recommend you to have a look at:

FAQ

CriticalStop()

Debug and Output Functions

These pages properly explain how the CriticalStop is used in Cinema 4D, how it can be used in plugins and what to expect when it's hit.

In you case, as already pointed out by @m_magalhaes , it's likely you're using a GeData::GetFilename() with a GeData whose type was not a Filename. Please recheck your code and if you don't spot the issue, provide us with an example or snippet to reproduce it.

Cheers, R

Thanks for the links. They'll come in handy on my next project, which will be in c++ (and I will be abusing the hell out of all the debugging options!).

Could it have been caused by the filename returning None? Is that even a thing or just something I noticed while I was missing any initialization on my Filename parameter? I can't see it being anything else... unless an empty string could trigger that error?

Thanks all!
Kevin