Accessing variables in c++ crashes maya

Accessing variables in c++ crashes maya

m_m_parsons
Participant Participant
824 Views
4 Replies
Message 1 of 5

Accessing variables in c++ crashes maya

m_m_parsons
Participant
Participant

Hello!

I don't quite know how to describe this.... I have a Maya plugin (for Maya 2017 update 5) that was working until a couple of weeks ago, but suddenly it started crashing Maya... After some hours of research, compiling, testing I reached the point where accessing some variables, for some reason, crashes Maya.... I have no idea why but e.g. if I do

 

startingFramesVec is a vector that contains many ints
int startFrameId = startingFramesVec[idx];

1)
MGlobal::displayInfo(MString("chosenFrame: ") + startFrameId);

2)
MGlobal::displayInfo(MString("chosenFrame: ") + startingFramesVec[idx]);

if I do 1, Maya crashes, if I do 2 it doesn't.... wth? o.O

But this is random... it can be Maya types, it can be normal types...

Does anyone have any idea how to solve this??? Please :')

Thank you!

 

0 Likes
825 Views
4 Replies
Replies (4)
Message 2 of 5

Anonymous
Not applicable

You are most likely overwriting memory somewhere in your plugin. If you have access to a memory debugger or bounds checking tool, use it. At very least use a debugger to get a stack trace: that might give you some clues to the problem.

0 Likes
Message 3 of 5

m_m_parsons
Participant
Participant

Do you recommend any tool? I've never done something like that... :S

0 Likes
Message 4 of 5

Anonymous
Not applicable

If you're on Windows then the easiest place to start is by scattering a few calls to _CrtCheckMemory in your code to see if you're corrupted the heap. And whatever platform you're on, run Maya, attach a debugger and get a callstack for your crash.

 

As for the memory debuggers, what you use depends upon your situation and the size of your bank account, but this Wikipedia page is a good place to start. While there are free tools available for all platforms the commercial ones are usually (but not always) easier to use.

 

Keep in mind that your plugin is effectively running as part of Maya so tools which, for example, require that you recompile or relink your code with special libraries will be of limited usefulness since their function will be limited to just your own code, not the rest of Maya. While they may find find areas of your code where you are directly overwriting memory, they are unlikely to find places where Maya is overwriting memory because you provided invalid parameters in an API call. That doesn't mean you shouldn't try them, just be aware of their limitations.

 

Some tools do not work well with Maya's graphical needs, particularly since the switch to Viewport 2.0. If you don't need Maya's UI to recreate your problem then be aware that Maya has a '-prompt' flag which will let you run MEL commands from a console/terminal window.

 

My preferred tool is valgrind/memcheck. It's free but it only runs on Linux and MacOS so you'd have to have one of those available to you. It functions by monitoring a program's memory accesses from the outside, meaning that it can monitor all of Maya, not just your plugin. If you plan on doing debugging on Linux be aware that the 'maya' command you run is just a shell script, not the final binary. The script provides -d and -dbgArg flags which can be used run the actual maya binary inside a debugger. The same may be true on MacOS, but I'm not sure.

 

Note that Maya is not the cleanest code ever written. A tool like valgrind/memcheck will find hundreds of potential problems just within Maya itself. You'll have to filter through a lot of chaff to find the nuggets which apply to your code. Back when the company was still Alias|Wavefront they used to have a valgrind "exceptions" file which could be fed into the tool to eliminate a lot of the known chatter. I don't know if they still maintain such a thing but it couldn't hurt to ask. Here again, running Maya with the '-prompt' flag can help by eliminating a ton of potential problems being flagged in the UI.

 

And of course there's always the time-honoured way of tracking down memory stompers: eliminate as much code as you can until you have the bare minimum which exhibits the error. Then step through it in a debugger. Scrutinize each line of code carefully. Question all of your assumptions about what *should* be going on and verify that that's what is *actually* going on by inspecting data and control flow either in a debugger or using print statements.

Message 5 of 5

m_m_parsons
Participant
Participant

Brilliant! Thank you so much for the reply! I still didn't manage to find it, but it is helping!

 

0 Likes