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
