Archived

This forum has been archived. Please start a new discussion on GitHub.

IceUtil::TimerTask::TimerTask() : Access violation reading location

Hello guys,

For our project's migration purpose; from ice 3.5 to 3.7.3 (and Visual Studio 2010 to 2017), I'm facing the unexpected error 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF when trying to construct an CallbackOutgoing object in a _iceI_begin_myMethodName proxy's method ... :

::IceInternal::OutgoingAsyncPtr result = new ::IceInternal::CallbackOutgoing(this, iceC_castor_internal_CorePropertiesManager_newSession_name, del, cookie, sync);

Actually when calling the constructor CallbackOutgoing (in OutgoingAsync.h file, line 777), it creates an IceUtil::Shared part of the instance, and by watching this variable, I see that everything is fine and well defined:

But while debugging in the previous constructor, it goes up in the hierarchy to call the inherited class constructor: OutgoingAsync and I see in this variable that the inherited IceUtil::TimerTask part looses its IceUtil::Shared part, as shown here:

Then, the crash happens:

Very strange!
Do you have any idea why/how explain this unexpected error please ? Very weird
It happens only when the code is about to invoke our proxies's methods, but not ice's.

I'm using the same base code (Slice definitions) as when the app was running with ice 3.5, and have reading the doc's upgrade section, I didn't have to change something related to the problem above I think ... :/

Thanks per advance for your help :smile:

Mehdi

Comments

  • xdm
    xdm La Coruña, Spain

    Hi Mehdi,

    This usually happen when you mix debug and release libraries, or if there is a mismatch with the compilers used to build the Ice libraries and the application.

    For Visual Studio 2017 you should be using the binaries from zeroc.ice.v141.3.7.3 NuGet package, are you using this binaries?

    You should check that you are building with the correct run-time settings, MDd for debug builds and MD for release buids, see:

    https://doc.zeroc.com/ice/3.7/release-notes/using-the-windows-binary-distributions#id-.UsingtheWindowsBinaryDistributionsv3.7-InformationforC++Developers

  • Hi Jose,

    Thank you for you reply :)
    I indeed used the binairies from zeroc.ice.v141.3.7.3 via NuGet package, but didn't put the correct flag of the Exception Handling Model: I put /EHa instead of /EHsc ... I'll change that, rebuild the whole project and let you know the result :)

    Thanks again.

    Mehdi

  • Hi Jose,

    Unfortunately it still crashes as previously despite the flag /EHsc in the configuration of VS2017 via the makefile routine. I'm wondering if the collocated others flags do not have undesirable impacts :\

    //Flags used by the CXX compiler during all build types.
    CMAKE_CXX_FLAGS:STRING=/bigobj /DWIN32 /D_WINDOWS /D_WIN32_WINNT=0x0502 /DWINVER=0x0501 /fp:precise /MP2 /Gy /W3 /Zc:wchar_t /EHsc /D_CRT_SECURE_NO_WARNINGS /D_SCL_SECURE_NO_WARNINGS /D_CONSOLE /DWIN32_LEAN_AND_MEAN /D_CRT_SECURE_NO_DEPRECATE /DBOOST_ALL_NO_LIB /DBOOST_THREAD_DONT_PROVIDE_DEPRECATED_FEATURES_SINCE_V3_0_0=1 /DBOOST_RESULT_OF_USE_DECLTYPE /DBOOST_ASIO_HAS_MOVE

    //Flags used by the CXX compiler during DEBUGbuilds.
    CMAKE_CXX_FLAGS_DEBUG:STRING=/D_DEBUG /MDd/Zi /Ob0 /Od /RTC1 /D_SECURE_SCL=1 /D_HAS_ITERATOR_DEBUGGING=1 /DTBB_USE_DEBUG /wd4512 /wd4127 /wd4244 /wd4267 /wd4482 /DOTL_ORA10G /DOTL_STL /DOTL_ORA_UTF8 /DOTL_ADD_NULL_TERMINATOR_TO_STRING_SIZE /DNOMINMAX

    //Flags used by the CXX compiler during RELEASEbuilds.
    CMAKE_CXX_FLAGS_RELEASE:STRING=/MD /Zi /O2 /Ob2 /Oi /Ot /Oy /GS- /arch:SSE2 /D_SECURE_SCL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DNDEBUG /wd4512 /wd4127 /wd4244 /wd4267 /wd4482 /DOTL_ORA10G /DOTL_STL /DOTL_ORA_UTF8 /DOTL_ADD_NULL_TERMINATOR_TO_STRING_SIZE /DNOMINMAX

    As confirmed earlier in my previous message, I downloaded the binaries zeroc.ice.v141.3.7.3 via NuGet package, and I put the whole package in another repository (because I had to follow a pattern structure of all third parties packages like Ice); where in a lib repository I put all the debug and release library files along together in this same folder lib, and in a bin repository I put all together debug and release binaries files in this bin folder ... as all debug binary/library file names are suffixed with the letter d, I shouldn't have any name conflicts ... do you agree with me ... ? :\ but with this doubt, I'll change the repository structure to let 2 separate folders, for Debug and Release to test ...

    Other interrogation also, in Visual Studio settings the C++ language standard is set to std:c++14. And I'm using the old c++98 Ice mapping ... normally it should be ok, do you confirm me that please ?

    Thank you very much for your help.

    Mehdi

  • xdm
    xdm La Coruña, Spain

    Are you getting this crash with an x64 Debug build?

    One thing in you build settings different to Ice build settings is /D_WIN32_WINNT=0x0502, we build Ice with /D_WIN32_WINNT=0x601

    Coping debug and release libraries to the same directory should not cause problems, just make sure that you use x64 libraries for x64 builds and Win32 libraries for Win32 builds.

    Using C++14 standard with C++98 mapping and Visual Studio shouldn't be a problem, this depends on the compiler compatibility of the different C++ standards but in our experience Visual Studio has not problems with regard to this.

  • xdm
    xdm La Coruña, Spain

    By the way if you can create a small test case than allow us to reproduce the problem I'm will be happy to look at it.

  • Mehdi
    edited April 2020

    Yes I'm getting this crash with x64 Debug build (we don't care about the Win32 build actually) ... I'm wondering if I don't have to delete /DWIN32 flag ... I'll test with /D_WIN32_WINNT=0x0601 and /DWINVER=0x0601 flags (we're working on Windows 7) and see if it's work ...

    Thanks again

    Mehdi

  • Mehdi
    edited April 2020

    Oh just received your second message in a row ...
    sure, thanks

    Mehdi

  • Hi Jose,

    Great news, it doesn't crash anymore ! :)

    Thanks to the settings /D_WIN32_WINNT=0x0601 and /DWINVER=0x0601 ... and big thanks to you ! :)

    I can continue now testing our app with the new ice 3.7 ...

    Have a good day :)

    Mehdi

  • xdm
    xdm La Coruña, Spain

    I'm glad you get it working