SI2014: exit doesn't kill process?

[Hirazi Blue]

Today I quickly wanted to install Softimage 2014 and its new license and I seem to have spotted a major bug, but I'd need some confirmation or an appropriate explanation before either blowing a fuse or give up on Softimage once and for all.
On my Windows 7 machine Softimage 2014 doesn't seem to kill its own process on exit. The XSI.exe process keeps visible in the Process Tab of the Windows Task Manager after exiting Softimage 2014 and SI2014 doesn't return its license to the License Manager, preventing usage of previous versions. Killing the process in the Task Manager would seem to be the only workaround.
I sure hope, I'm missing something, as this would be ridiculous (to say the least).


PS After killing the XSI.exe process the usage of previous versions is possible without a hitch.

[xsisupport]

Maybe XSI.exe crashed on exit. Check if it is writing out a .dmp file in your Softimage User location.

[rray]

Do you happen to have any python plugin installed that imports windows libs? (f.ex. xpop, rcTools do that)
It crashes on exit when this is the case (Seems like a new bug)

[xsisupport]

Do you happen to have any python plugin installed that imports windows libs? (f.ex. xpop, rcTools do that)
It crashes on exit when this is the case (Seems like a new bug)

Yeah, I have rcTools, and python27.dll was at the top of the call stack!

[Hirazi Blue]

Softimage indeed writes a dump file (I should have thought of checking that first) and after removing RCTools and a few other addons wholesale (as just removing RCTools didn't do the trick), it seems to work as advertised. Thank you both.

@rray - Is there a workaround already? I would very much be able to keep on using the RCTools... And how would such a workaround apply to other addons/plugins?

[rray]

Looks like as a workaround reverting back to python 2.6.6 works.. I doubt there'll be any kind of negative consequences from doing so

http://www.python.org/download/releases/2.6.6/ / http://sourceforge.net/projects/pywin32 ... ild%20218/

I'll look into how I can fix it from the plugin side, but that might not work since already an empty plugin that only imports one win32** lib leads to the late crashes.

this might be a bug in python 2.7+pywin32 extensions: http://stackoverflow.com/questions/1046 ... s-imported

[Chris Chia]

Just a side note:

Python 2.6.4 (this is the version we use in Softimage 2013)
pywin32 2.1.2 for Py2.6 (I used this: http://sourceforge.net/projects/pywin32/files/pywin32/Build%20212/pywin32-212.win-amd64-py2.6.exe/download)

Just point the PYTHONPATH env variable: to where your python 2.6.4 is installed (for example: C:\Python26)

This is just a workaround.

We will still investigate on why some python scripts won’t work in Py2.7 causing XSI process not to free up

[iamVFX]

nice

[Hirazi Blue]

this might be a bug in python 2.7+pywin32 extensions: http://stackoverflow.com/questions/1046 ... s-imported

Looking at that bug report, the pywin32 people can't seem to reproduce it, so it will probably not be fixed anytime soon (it was reported in 217 and according to the changelog it wasn't fixed in 218). These kind of things sometimes make me wonder what happens during a Softimage beta. Reverting to internal Python 2.6 (and the corresponding pywin) before launch should have been easily doable, if only someone had noticed...

@Chris Chia - Thanks for specifying the necessary steps!
Maybe you could get someone to update this download with the most recent files.

[xsisupport]

@Chris Chia - Thanks for specifying the necessary steps!
Maybe you could get someone to update this download with the most recent files.

I think that was a special python build for 2010 only, you couldn't get it anywhere else.
Now you can download Python and pywin from the usual places.

[Hirazi Blue]

You're right IIRC, but my point was, that having to revert to an external Python would be (even) easier if AD offered the necessary files in one simple rar/zip.
;)

edit & PS: for those "on" Previous Versions with SI2013 (SP1) still installed: couldn't you just point PYTHONHOME to that specific "internal" Python?

[rray]

Re: PS: Probably, that should be a full python installation inside the bin folder

[rray]

PS: Welcome on board Chris!

[Chris Chia]

These kind of things sometimes make me wonder what happens during a Softimage beta. Reverting to internal Python 2.6 (and the corresponding pywin) before launch should have been easily doable, if only someone had noticed...

Hi Hirazi,
If you would like to contribute to Softimage beta testing,
do let me know

I could send you an invite, but it comes with a NDA (meaning you can't disclose any beta info to this forum)

Regards,
Chris

[Hirazi Blue]

Thanks for the offer. I'll have to think about it.
My gripe wasn't with the beta list not doing a good job BTW, but with the sad fact there are always (sometimes seemingly small, but often quite fundamental) things the whole beta list seems to have missed (like for instance the infamous render time lag of a few versions back). Changing to a new Python version would seem to result in some additional testing I would think and the beta members would be able to test it with some common 3rd party plugins (like RCTools). And yes, I know it's easier criticizing the beta list "from the outside".
;)

[Hirazi Blue]

Just wanted to let you know, I just got word, the problem I reported earlier
now has officially been logged and has been designated as

SOFT-8889 Plugin conflict with Python 2.7 causes XSI Process not to free up

Here's hoping for a quick resolution (apart from the "workaround")