Hi Mike, Thanks for your support ;-)
Shing On Thu, Jan 3, 2013 at 5:13 PM, Mike Wong | artixels.gmail < [email protected]> wrote: > Hi Shing, > > I support your suggestion, it could easily trigger cross-runtime problems. > > Mike > > > On Thu, Jan 3, 2013 at 4:50 PM, Chishing Yip <[email protected]>wrote: > >> >> Hi, >> >> I still wonder if making a non-STL API could be an alternative or not, I >> prefer calling API without any STL container, if possible. >> >> Best, >> Shing >> >> On Wed, Jan 2, 2013 at 6:18 PM, The Foundry Support < >> [email protected]> wrote: >> >>> Hello Shing, >>> >>> Thanks for the update, I'm glad to hear that you've narrowed down the >>> cause of >>> the crash. >>> >>> >>> Kind Regards, >>> Jake >>> >>> >>> >>> Chishing Yip <[email protected]> wrote: >>> >>> > Hi Jake & Peter, >>> > >>> > If I compile my plugin with "/MT", there is no crash. >>> > Indeed the crash was from the runtime library, I confirmed that the >>> runtime >>> > library was introduced from one of my external libraries, so the >>> problem is >>> > fully on my side, I think you can close the ticket now. >>> > >>> > Sorry for the trouble and really grateful for the help. >>> > Shing >>> > >>> > On Fri, Dec 21, 2012 at 12:44 AM, Chishing Yip <[email protected] >>> >wrote: >>> > >>> > > Hi Jake, >>> > > >>> > > Thank your very much for the support, I am still testing on my site >>> to >>> > > figure out what's wrong, will keep you and Peter posted if this >>> ticket can >>> > > be closed or not. >>> > > >>> > > Have a good holiday, to both of you! >>> > > >>> > > Shing >>> > > >>> > > >>> > > >>> > > On Thu, Dec 20, 2012 at 10:35 PM, The Foundry Support < >>> > > [email protected]> wrote: >>> > > >>> > >> Hi Shing, >>> > >> >>> > >> Thanks for sending the example code and extra information to us. >>> > >> >>> > >> My colleague Peter who was looking into this is now on annual leave >>> until >>> > >> the >>> > >> new year and today is my last day too. I'll keep this support >>> ticket >>> > >> open so >>> > >> that we can look into this again in the new year. >>> > >> >>> > >> In the meantime, please let us know if you have any further >>> questions. >>> > >> >>> > >> Happy Christmas and Kind Regards, >>> > >> Jake >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> Chishing Yip <[email protected]> wrote: >>> > >> >>> > >> > Hi Peter, >>> > >> > >>> > >> > See attachment for the full source code. I changed based on the >>> > >> > 'MyNode.cpp' ( the one that I got problem with SceneView_knob >>> last time >>> > >> ). >>> > >> > >>> > >> > To clear any unknown compilation problem, I made the build in >>> command >>> > >> line >>> > >> > with: >>> > >> > >>> > >> > C:\build > cl.exe /I"C:\Program Files\Nuke7.0v1\include" /EHsc >>> > >> MyNode.cpp >>> > >> > /link /dll /OUT:MyNode.dll "C:\Program >>> Files\Nuke7.0v1\DDImage.lib" >>> > >> > >>> > >> > >>> > >> > I also tried to add "/Zi" and linker flag "/DEBUG" to get >>> > >> > the accessible calling stack. >>> > >> > >>> > >> > To replicate the crash: >>> > >> > - compiler MyNode.cpp >>> > >> > - create MyNode, type some letters in the 'file path' >>> > >> > - select some of the items in SceneView_knob, switch viewer to 3D >>> --> >>> > >> crash >>> > >> > >>> > >> > OR: >>> > >> > - create MyNode, connect to 'Scene', then connect to >>> 'ScanlineRender', >>> > >> then >>> > >> > connect to 'viewer' >>> > >> > - press the 'calc hash' button in the panel --> crash >>> > >> > >>> > >> > OR: >>> > >> > - create MyNode, connect to 'Scene', then connect to >>> 'ScanlineRender', >>> > >> then >>> > >> > connect to 'viewer' >>> > >> > - save the scene >>> > >> > - launch Nuke 7 and load the scene --> crash >>> > >> > >>> > >> > Here is the call stack: >>> > >> > >>> > >> > > ntdll.dll!0000000077a932d0() >>> > >> > [Frames below may be incorrect and/or missing, no symbols >>> loaded for >>> > >> > ntdll.dll] >>> > >> > kernel32.dll!00000000774d300a() >>> > >> > MyNode.dll!free(void * pBlock) Line 51 C >>> > >> > MyNode.dll!std::allocator<unsigned int>::deallocate(unsigned >>> int * >>> > >> _Ptr, >>> > >> > unsigned __int64 __formal) Line 183 C++ >>> > >> > MyNode.dll!std::vector<unsigned int,std::allocator<unsigned int> >>> > >> > >::_Tidy() Line 1309 C++ >>> > >> > MyNode.dll!std::vector<unsigned int,std::allocator<unsigned int> >>> > >> > >::~vector<unsigned int,std::allocator<unsigned int> >() Line >>> 705 + 0xa >>> > >> > bytes C++ >>> > >> > MyNode.dll!MyNode::calcHash() Line 143 C++ >>> > >> > MyNode.dll!MyNode::knob_changed(DD::Image::Knob * k) Line 207 >>> C++ >>> > >> > Nuke7.0.exe!00000001405af0e4() >>> > >> > Nuke7.0.exe!00000001405aea57() >>> > >> > Nuke7.0.exe!000000014092f2c4() >>> > >> > Nuke7.0.exe!0000000140930737() >>> > >> > QtCore4.dll!000000007274af1f() >>> > >> > QtGui4.dll!0000000071ae5f13() >>> > >> > QtGui4.dll!00000000718a1c0f() >>> > >> > QtGui4.dll!00000000718a3303() >>> > >> > QtGui4.dll!00000000718a35ea() >>> > >> > QtGui4.dll!00000000715dac05() >>> > >> > QtGui4.dll!00000000715903b6() >>> > >> > QtGui4.dll!000000007159210c() >>> > >> > Nuke7.0.exe!0000000140615c2e() >>> > >> > QtCore4.dll!0000000072737d92() >>> > >> > QtGui4.dll!000000007159163e() >>> > >> > QtGui4.dll!00000000715f2808() >>> > >> > QtGui4.dll!00000000715f5146() >>> > >> > user32.dll!00000000775e9bd1() >>> > >> > user32.dll!00000000775e98da() >>> > >> > QtCore4.dll!000000007275d05a() >>> > >> > QtGui4.dll!00000000715f46e5() >>> > >> > QtCore4.dll!000000007273734a() >>> > >> > QtCore4.dll!000000007273b450() >>> > >> > Nuke7.0.exe!0000000140603fe7() >>> > >> > Nuke7.0.exe!0000000140cd1f29() >>> > >> > Nuke7.0.exe!00000001410f3d16() >>> > >> > Nuke7.0.exe!0000000140cee3f6() >>> > >> > >>> > >> > I might use SceneView_knob in a wrong way. >>> > >> > >>> > >> > Thanks a lot, >>> > >> > Shing >>> > >> > >>> > >> > On Mon, Dec 17, 2012 at 10:49 PM, Chishing Yip < >>> [email protected] >>> > >> >wrote: >>> > >> > >>> > >> > > Hi Peter, >>> > >> > > >>> > >> > > The suggested wrapper functions can be added to existing >>> > >> SceneView_KnobI >>> > >> > > interface without removing the STL version, my plugin runs fine >>> on >>> > >> Linux >>> > >> > > and OSX with getSelectedItems() and getImportedItems() . >>> > >> > > >>> > >> > > I will dump the backtrace when I back to the office tomorrow ( >>> GMT+8 >>> > >> ) and >>> > >> > > send the sample code to you asap. >>> > >> > > >>> > >> > > Best, >>> > >> > > Shing >>> > >> > > >>> > >> > > >>> > >> > > >>> > >> > > On Mon, Dec 17, 2012 at 10:11 PM, Peter Crossley < >>> > >> > > [email protected]> wrote: >>> > >> > > >>> > >> > >> Hi Shing, >>> > >> > >> >>> > >> > >> The additions to the interface you've detailed seem like a >>> reasonable >>> > >> > >> request, however we can't break NDK compatibility until the >>> next >>> > >> major >>> > >> > >> release. I would suggest you contact >>> [email protected] >>> > >> > >> with a feature request for this. >>> > >> > >> >>> > >> > >> I would also like to get to the bottom of your crashes. There >>> > >> shouldn't >>> > >> > >> be any problems calling these functions unless you're mixing >>> crt >>> > >> versions. >>> > >> > >> >>> > >> > >> Would it be possible for you to send us a code sample that >>> causes the >>> > >> > >> crash? >>> > >> > >> >>> > >> > >> Regards, >>> > >> > >> >>> > >> > >> Peter. >>> > >> > >> >>> > >> > >> >>> > >> > >> On 17/12/2012 13:12, Chishing Yip wrote: >>> > >> > >> >>> > >> > >> Hi Tom, >>> > >> > >> >>> > >> > >> Thanks a lot for your reply. >>> > >> > >> We always make release build on windows, we have developed >>> windows >>> > >> pluginfor two years without any >>> > >> > >> STL/compiler version problem in Nuke 6.3, this problem is new >>> to us. >>> > >> > >> >>> > >> > >> As I can see SceneView_knob is the only one that has this >>> problem so >>> > >> > >> far in our plugins, is adding few wrappers an alternative? >>> e.g. we >>> > >> are >>> > >> > >> using: >>> > >> > >> const std::vector< std::string >& SceneView_KnobI::menus() >>> const; >>> > >> > >> const std::vector< std::string >& >>> SceneView_KnobI::getItemNames() >>> > >> const; >>> > >> > >> void SceneView_KnobI::getImportedItems( std::vector< unsigned >>> int >& >>> > >> > >> items ) const; >>> > >> > >> void SceneView_KnobI::getSelectedItems( std::vector< unsigned >>> int >& >>> > >> > >> items ) const; >>> > >> > >> >>> > >> > >> but we could also do the same thing without any STL interface >>> if we >>> > >> > >> could have wrappers like these: >>> > >> > >> >>> > >> > >> unsigned int SceneView_KnobI::numOfMenus() const; >>> > >> > >> const char* SceneView_KnobI::getMenuItem( unsigned int >>> menuIndex ) >>> > >> const; >>> > >> > >> >>> > >> > >> unsigned int SceneView_KnobI::numOfItemNames() const; >>> > >> > >> const char* SceneView_KnobI::getItemName( unsigned int >>> itemIndex ) >>> > >> const; >>> > >> > >> >>> > >> > >> unsigned int SceneView_KnobI::numOfItems() const; >>> > >> > >> bool SceneView_KnobI::isImportedItem( unsigned int itemIndex ) >>> const; >>> > >> > >> bool SceneView_KnobI::isSelectedItem( unsigned int itemIndex ) >>> const; >>> > >> > >> >>> > >> > >> in the private implementation in SceneView_KnobI.cpp ( or any >>> > >> private . >>> > >> > >> cpp implementation inside Nuke ): >>> > >> > >> >>> > >> > >> unsigned int SceneView_KnobI::numOfMenus() const >>> > >> > >> { >>> > >> > >> return menu.size(); >>> > >> > >> } >>> > >> > >> const char* SceneView_KnobI::getMenuItem( unsigned int >>> menuIndex ) >>> > >> const >>> > >> > >> { >>> > >> > >> return menu[ menuIndex ].c_str(); >>> > >> > >> } >>> > >> > >> >>> > >> > >> unsigned int SceneView_KnobI::numOfItemNames() const >>> > >> > >> { >>> > >> > >> return getItemNames.size(); >>> > >> > >> } >>> > >> > >> const char* SceneView_KnobI::getItemName( unsigned int >>> itemIndex ) >>> > >> const >>> > >> > >> { >>> > >> > >> return getItemNames[ menuIndex ].c_str(); >>> > >> > >> } >>> > >> > >> >>> > >> > >> unsigned int SceneView_KnobI::numOfItems() const >>> > >> > >> { >>> > >> > >> return /* the total items scene view knob holds*/ ; >>> > >> > >> } >>> > >> > >> bool SceneView_KnobI::isImportedItem( unsigned int itemIndex ) >>> const >>> > >> > >> { >>> > >> > >> return /*if getImportedItems() contains the input itemIndex or >>> not*/; >>> > >> > >> } >>> > >> > >> bool SceneView_KnobI::isSelectedItem( unsigned int itemIndex ) >>> const >>> > >> > >> { >>> > >> > >> return /*if getSelectedItems() contains the input itemIndex or >>> not*/; >>> > >> > >> } >>> > >> > >> >>> > >> > >> In this way, we don't need to deal with any STL interface but >>> we >>> > >> could >>> > >> > >> construct the item list inside our plugin by ourselves, so >>> there >>> > >> won't >>> > >> > >> be any STL compatibility issue between Nuke and any 3rd party >>> > >> plugins, >>> > >> > >> and since these are all wrappers I don't think that's >>> difficult to >>> > >> > >> implement. >>> > >> > >> >>> > >> > >> We understand the API in Nuke 7.0 has been frozen, if above >>> > >> suggestion is >>> > >> > >> an acceptable alternative, we could wait until Nuke 7.1 >>> release, >>> > >> what do >>> > >> > >> you think? >>> > >> > >> >>> > >> > >> Thanks again for your reply. >>> > >> > >> Best, >>> > >> > >> Shing >>> > >> > >> -- >>> > >> > >> Zhicheng YE - Shing >>> > >> > >> the /*jupiter jazz*/ group - visual research >>> > >> > >> mercenaries of jupiter jazz limited - hong kong >>> > >> > >> www.jupiter-jazz.com >>> > >> > >> >>> > >> > >> >>> > >> > >> On Mon, Dec 17, 2012 at 6:58 AM, Tom Ward < >>> [email protected]> >>> > >> wrote: >>> > >> > >> >>> > >> > >>> Hi Paolo, >>> > >> > >>> >>> > >> > >>> The version of VS2010 that Nuke is compiled against is indeed >>> > >> > >>> 16.00.30319.01 and as far as I know there have been no >>> breaking CRT >>> > >> > >>> changes in 2010 (unlike 2005) so don't think that would be the >>> > >> problem >>> > >> > >>> >>> > >> > >>> Are you definitely always linking against the release >>> version of >>> > >> the >>> > >> > >>> CRT? As we don't ship the debug versions of DDImage (or Nuke) >>> you >>> > >> need to >>> > >> > >>> always build release versions of your plugins for Windows, not >>> > >> doing so >>> > >> > >>> usually results in STL problems like you're apparently seeing. >>> > >> > >>> >>> > >> > >>> Hope that helps >>> > >> > >>> >>> > >> > >>> Tom >>> > >> > >>> >>> > >> > >>> On Sun, Dec 16, 2012 at 12:33 PM, Paolo Berto < >>> > >> [email protected]>wrote: >>> > >> > >>> >>> > >> > >>>> Hi Fellaz, >>> > >> > >>>> >>> > >> > >>>> we mailed on nuke-dev but got no answers. >>> > >> > >>>> >>> > >> > >>>> In a nutshell, we have a plugin which uses SceneView_knob >>> in Nuke >>> > >> > >>>> 7.0, it always crashes after accessing >>> > >> SceneView_KnobI::getSelectedItems() >>> > >> > >>>> or SceneView_KnobI::getImportedItems(), to us this looks >>> like a >>> > >> STL version >>> > >> > >>>> related problem. >>> > >> > >>>> >>> > >> > >>>> Our compiler version: >>> > >> > >>>> >>> > >> > >>>> > cl.exe >>> > >> > >>>> Microsoft (R) C/C++ Optimizing Compiler Version >>> > >> 16.00.30319.01 for >>> > >> > >>>> x64 >>> > >> > >>>> > link.exe >>> > >> > >>>> Microsoft (R) Incremental Linker Version >>> 10.00.30319.01 >>> > >> for x64 >>> > >> > >>>> >>> > >> > >>>> We installed MSVC 2010, without SDK 7.1, without 2010 SP1. >>> > >> > >>>> >>> > >> > >>>> How can we setup the correct development environment for >>> Nuke 7.0 >>> > >> ? >>> > >> > >>>> Which compiler ( and /exact/ version ) Nuke 7.0 was compiled >>> > >> against? >>> > >> > >>>> >>> > >> > >>>> Best, >>> > >> > >>>> >>> > >> > >>>> >>> > >> > >>>> -- >>> > >> > >>>> pbd >>> > >> > >>>> >>> > >> > >>>> paolo berto durante >>> > >> > >>>> space cowboy // jupiter jazz ltd // hong kong >>> > >> > >>>> https://atomkraft.hk >>> > >> > >>>> -- >>> > >> > >>>> >>> > >> > >>>> >>> > >> > >>>> >>> > >> > >>> >>> > >> > >>> >>> > >> > >>> >>> > >> > >>> -- >>> > >> > >>> Tom Ward, Software Engineer >>> > >> > >>> The Foundry, 6th Floor, The Communications Building, >>> > >> > >>> 48 Leicester Square, London, UK, WC2H 7LT >>> > >> > >>> Tel: +44 (0)20 7434 0449 <%2B44%20%280%2920%207434%200449> >>> Web: >>> > >> > >>> www.thefoundry.co.uk >>> > >> > >>> >>> > >> > >>> The Foundry Visionmongers Ltd. >>> > >> > >>> Registered in England and Wales No: 4642027 >>> > >> > >>> >>> > >> > >>> >>> > >> > >> >>> > >> > >> -- >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > >> >>> > >> > > >>> > >> > > >>> > >> > >>> > >> >>> > >> >>> > >> >>> > >> -- >>> > >> The Foundry Customer Support >>> > >> 6th Floor, The Communications Building, 48 Leicester Square, London >>> WC2H >>> > >> 7LT, >>> > >> UK +44 (0)20 7968 6828 >>> > >> 618 Hampton Drive, Venice, CA, 90291, USA +1 310 399 4555 >>> > >> Web: www.thefoundry.co.uk >>> > >> Customer Support: 09:30-18:00 GMT / 08:30 - 17:00 PST >>> > >> >>> > >> The Foundry Visionmongers Ltd • Registered in England and Wales No: >>> > >> 4642027 >>> > >> >>> > >> >>> > > >>> > > >>> > >>> >>> >>> >>> -- >>> The Foundry Customer Support >>> 6th Floor, The Communications Building, 48 Leicester Square, London WC2H >>> 7LT, >>> UK +44 (0)20 7968 6828 >>> 618 Hampton Drive, Venice, CA, 90291, USA +1 310 399 4555 >>> Web: www.thefoundry.co.uk >>> Customer Support: 09:30-18:00 GMT / 08:30 - 17:00 PST >>> >>> The Foundry Visionmongers Ltd • Registered in England and Wales No: >>> 4642027 >>> >>> >> >> >> _______________________________________________ >> Nuke-dev mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> >> > > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > >
_______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
