Fatal error with Maya and Panda's python (suggested fix)

Hey everyone,

I’m not entirely sure how many are aware of this problem but currently the maya egger has issues when it comes to python libraries. The way I understand the problem is that both maya and panda try to initialize python at the same time. Currently the egger throws an exception that is NOT handled via the executionenvironment.cxx in the source. This causes a fatal error in maya2egg (at least with the 2010 version). There is a fix for this problem, but it’s more of a workaround. A real stable fix would have to come from Autodesk and how they initialize any python libraries inside the OpenMaya API. However, the workaround is simply to catch the exception and do nothing with it. Like this:

#ifdef HAVE_PYTHON
	  // If we're running from Python code, read out sys.argv.
	  if (Py_IsInitialized()) {
		  
		  PyObject* obj = NULL;
		  try{
			  PySys_GetObject((char*) "argv");
		  }catch(...){}
		  if (obj) {
			  Filename main_dir = Filename::from_os_specific(PyString_AsString(PyList_GetItem(obj, 0)));
			  if (main_dir.empty()) {
				  // We must be running in the Python interpreter directly, so return the CWD.
				  return get_cwd().to_os_specific();
			  }
			  main_dir.make_absolute();
			  return Filename(main_dir.get_dirname()).to_os_specific();
		  }
	  }
#endif

The current code in executionenvironment.cxx looks like this.

#ifdef HAVE_PYTHON

  // If we're running from Python code, read out   sys.argv.

    if (Py_IsInitialized()) {
      PyObject* obj = PySys_GetObject((char*) "argv");

      if (obj) {

        Filename main_dir = Filename::from_os_specific(PyString_AsString(PyList_GetItem(obj, 0)));

        if (main_dir.empty()) {
          // We must be running in the Python interpreter directly, so return the CWD.

          return get_cwd().to_os_specific();
        }

        main_dir.make_absolute();
        return 

   Filename(main_dir.get_dirname()).to_os_specific();

      }	
    }
		

#endif

Sorry for the poor paste job from the CVS code, but you get the idea. Would anyone object to commiting this fix into CVS sometime soon? Currently the egger is unusable without it. I understand it will affect a lot of other utilities so that’s why I posted to double check. Thanks in advance

~Andrew

Hmm, it seems a little iffy. If we’re running with two different versions of Python in memory at the same time, anything can happen, not just exceptions in the call to PySys_GetObject().

I think the best solution is to compile maya2egg against a version of Panda that has been compiled without any Python support at all. It can be compiled with static libraries so that the resulting maya2egg.exe binary has no dependencies on any Panda dll’s, and can then be used in conjunction with a standard Panda installation.

I do realize, however, that it can be pretty inconvenient to have to compile an entirely separate branch of Panda just to have a working maya2egg, and a simpler workaround would be preferred.

But relying on an exception to be thrown still seems like trouble. It would be better not to call Py_IsInitialized() in the first place, in this case. Hmm, that seems like a hard thing to arrange, though, since this call is being made at static init time, as the prc files are being read–this means we don’t have any way to pre-load a configuration variable to tell it not to do that. Bleah.

David

Thanks for the feedback David. I tried to compile the egger against a static build as I had discussed with you a month or so ago. I didn’t have much success. I kept getting a whole bunch of libraries that were basically empty because symbols had been defined earlier. I may have to just try and build a VS project for the egger and copy any panda includes that it depends on at some point. Not really sure if that will meet with much success either. I know now that there is a way to build panda statically via makepanda, but I like i mentioned before I hit huge problems whenever the egger went to link with those static libraries.

Anyway,I don’t have a problem keeping this execption business an “in-house” fix at all, but I wanted to throw it out there in case anyone else was hitting the snag. I understand the really ugly nature of it, and so I wasn’t just going to have it committed without posting here first. I guess there’s no way around it unless Autodesk decides to change things on there end somehow. We’ll keep this out of the repository for now.

~Andrew

Well, I am certainly in favor of making a working solution available to the general public.

I’m surprised that you had so much difficulties making a static build. I use that feature occasionally (via ppremake), and it usually doesn’t give me troubles, though it’s been a little while since I’ve tried it. Let me try it again.

David

Thanks! Any help on the matter would be terrific. I’ve been trying to avoid installing CyGwin and running ppremake, but if you find a way to pull it off at any point I’d be willing to give it a go. Granted I know there have been some recent commits dealing with static linking in makepanda, but I still don’t know if the linker in VS is playing nice with the way the libs get built (at least with the egger anyway).