I’ve written a Maya API plugin.  When I update the plugin, it crashes any instances of Maya that have the plugin loaded - not just on my machine, but acorss our entire network.  This is, of course, completely unacceptable during production.

Is anyone else experiencing this & if so, how are you getting around it?

Our environment uses SVN for plugins/scripts. that’s how we update it.
Plugins are tested on “bare” machines to make sure that there are no weird dependencies (like using dll/etc from VS.net that are not deployed all over the place).

We hit a big snag after upgrading VS.net to 2005 (on maya 7.0), since the plugins would be depending on the msvc71.dll when maya shipped with the 7.0.

use the “depends” tool from visual studio to make sure that all the dependency from the mll are actually deployed with it.
(i hope this makes sense)

epac 23 May 2008 11:55 PM

Our environment uses SVN for plugins/scripts. that’s how we update it.
Plugins are tested on “bare” machines to make sure that there are no weird dependencies (like using dll/etc from VS.net that are not deployed all over the place).

We hit a big snag after upgrading VS.net to 2005 (on maya 7.0), since the plugins would be depending on the msvc71.dll when maya shipped with the 7.0.

use the “depends” tool from visual studio to make sure that all the dependency from the mll are actually deployed with it.
(i hope this makes sense)

Thanks for the reply, but the error is not with the plugin, it’s with Maya.  For example, here’s a repeatable test:

compile your plugin
load up maya
load the plugin
put it in the scene however you prefer.  In my case, I open a script window & type “createNode myPlugin”
now reinstall the plugin (overwrite the dso/dll - no programming changes necessary - just recompile & overwrite)
switch back to maya & insta-crash - Segmentation fault.

Don’t know if it matters, but I’m using linux.

The plugin works great & is used by most of my facility… which means that most people’s maya will crash if I update the plugin.  This leaves my plugin updates to a cron job that runs at 7am - so I only get one system-wide update a day.  No good.  There must be a better way?

edit: unless you mean that part of opening maya is to “svn co” a repository of binary plugins to the local maya plugin path.  Is that what you mean by using svn to update plugins/scripts?

if your plugin provides commands, use eval rather than `backquotes` to call them.  Something to do with how maya manages memory.

Updating a plugin on the network while a user is online is probably a bad idea.

I usually get the user to run a batch file that starts maya, rather than calling it directly, which can copy or checkout the plugin and other files before maya loads. 

Al.

epac 23 May 2008 11:55 PM

Our environment uses SVN for plugins/scripts. that’s how we update it.
Plugins are tested on “bare” machines to make sure that there are no weird dependencies (like using dll/etc from VS.net that are not deployed all over the place).

BrianK 24 May 2008 12:30 AM

The plugin works great & is used by most of my facility… which means that most people’s maya will crash if I update the plugin.  This leaves my plugin updates to a cron job that runs at 7am - so I only get one system-wide update a day.  No good.  There must be a better way?

edit: unless you mean that part of opening maya is to “svn co” a repository of binary plugins to the local maya plugin path.  Is that what you mean by using svn to update plugins/scripts?

our “userSetup.mel” runs a number of script on startup (to handle all our custom menus, ui, etc). part of that is to update all the mel and mll scripts. we use SVN to “update” and manage those files. we found out that the scripts runs before the plugins are loaded (from the preferences—at least that’s what it looks like). so we simply run a script that gets the new mll when maya starts. the problem is that each user ends up with a whole copy of all the mel/mll files (not shared any more). but we figured that it’s better than nothing. it also allows for people to take laptops out to demos and such…

and yes, the whole updating mechanism is based on subversion… we have a simple bootstrapper mel script that checks out the whole setup when needed (makes the maya startup take a couple of seconds on the very first launch… but that’s acceptable...).

on windows, you can’t change the file while maya has the plugin loaded. my guess is that maya is using a mechanism similar to “mmap” to get the file loaded. mmap maps files to memory, without necessarily loading them into RAM. so if you have the file mmaped, and you change the file, you’re essentially messing up the memory that maya is using, hence the crash.

(someone from Autodesk can confirm, or not...)

Thanks
epac

Interesting idea re: versioning system to check out binary plugins on application launch.  I don’t like it, but can live with it.  ;)

Thanks for the responses.