Menu ▾ ▴

U3D Lib's Cause Process to Hang on App Exit

U3D Sample Software Forum
henry
2010-08-31
2013-05-28

  • henry

    henry - 2010-08-31

    We have an unusual situation where it appears the U3D libraries are preventing the application process from shutting down.  I'm wondering if anyone might have some idea as to what might be causing this or where to potentially look in the source code for solutions.
    Here is a description of the setup.  From a managed .Net 2005 (i.e. C#) application we are calling into a COM server (i.e. DLL) which links against the following U3D libraries:

    DataTypes.lib
    IFXCore.lib
    IFXKernel.lib
    Platform.lib
    wildcards.lib

    When the application is shut down the process hangs.  This happens regardless of whether any U3D code is executed.  The act of loading the COM server DLL is sufficient to cause the problem.   If I remove the dependence on U3D libraries the problem goes away.

    Unfortunately the problem does not reproduce in a debug environment, however, using print statements I've confirmed the process is shutting down normally.   I'm confident all references to objects created by the server are released.  In fact I'm seeing the destructors on the objects being called when their reference count drops to zero.

    I've gone so far as to try and force the DLL to unload.  That can be accomplished with CoFreeUnusedLibraries.  I've confirmed DLLCanUnloadNow is called on the COM Server and true is being returned.  In these cases CoFreeUnusedLibraries hangs.

    I'm seeing this in WXP, Vista, and W7.  Any suggestions on what might be happening, or some way to track down the issue would be greatly appreciated. 

     

  • Michail Vidiassov

    Michail Vidiassov - 2010-09-01

    There are no such libraries in the original Intel distribution.
    It seems you have already substantially changed the build (and, likely, dynamic loading) process.
    Working with the original code I had problems when the core library (or plugins?) refused to unload if  some memory regions allocated for shared U3D objects were not freed. Not sure if it is relevant to your problem.

     

  • henry

    henry - 2010-09-01

    mvid,

    Although its been a while,  I'm fairly confident those libraries were generated using the standard U3D distribution (i.e. U3D_A_061228_5.zip).   We followed the instructions laid out in U3D.chm.  Specifically the build procedure for "Microsoft Visual Studio .NET 2003 IDE".  This involves using cygwin.  At the end of that process one ends up with a Visual Studio solution file (i.e. U3D.sln).  If you open that solution there are clearly projects for generating the libraries I've listed. 

    Regardless, what was the solution to your issues with the core library?  Were you able to force the library to unload?  If so how?  Where exactly in the source code would you recommend looking for potential problems when it comes to unloading?

    Thanks 

     

  • Michail Vidiassov

    Michail Vidiassov - 2010-09-01

    Oh, I did not deal much with that build path (cygwin to run Intel proprietary build system to get MSVS solution) and generally dislike native Intel build system.
    I moved to cmake on my Mac get makefiles and XCode project and tested that cmake produced working MSVS solution,
    without going into details of how MSVS works.

    Since you get problems without running any U3D code my issues are most likely irrelevant to your problems.
    I had to watch g_countActiveObjects variable (internal U3D counter of allocated objects) and look for places in code where some objects were not deleted if it turned out the counter was not zero at the time when a dynamic U3D module was to be unloaded (thus preventing unloading).
    You may take a look at my repackaged sources, they have that tiny fixes applied.

    As a workaround for build problems - drop the libraries completely, compile the files from U3D source required to build the static part with your source - they are just 25 (look for IFXCoreStatic_SRCS in my CMakeLists.txt).
    The only other part of U3D libs to build your source will be headers, while at runtime you will need DLL files.
    May be cmake-produced MSVS solution is sufficiently different from the one coming from native Intel build system.

    Consider extending your solution for building U3D DLL libraries doing that by hand instead of using output of Intel build system - again, use  CMakeLists.txt as for guidelines, since it is rather explicit as to what goes where. It this case you may able to debug your code with more ease.

     

  • henry

    henry - 2010-09-01

    We managed to solve the problem by changing the libraries we link against.  Here are the before and after link dependencies:

    Link Libraries causing process hang issues:
      "$(DIR_U3D_SDK)\Source\RTL\Build\All\Release\CorePluginStatic\IFXCorePluginStatic.lib"
      "$(DIR_U3D_SDK)\Source\RTL\Build\All\Release\DataTypes\DataTypes.lib"
      "$(DIR_U3D_SDK)\Source\RTL\Build\All\Release\Core\IFXCore.lib"
      "$(DIR_U3D_SDK)\Source\RTL\Build\All\Release\Kernel\IFXKernel.lib"
      "$(DIR_U3D_SDK)\Source\RTL\Build\All\Release\Platform\Platform.lib"
      "$(DIR_U3D_SDK)\Source\RTL\Build\All\Release\WildCards\wildcards.lib"

    Link libraries exiting without hang:
       "$(DIR_U3D_SDK)\Source\RTL\Build\All\Release\CoreStatic\IFXCoreStatic.lib"
       "$(DIR_U3D_SDK)\Source\RTL\Build\All\Release\DataTypes\DataTypes.lib"
       "$(DIR_U3D_SDK)\Source\RTL\Build\All\Release\Platform\Platform.lib"
       "$(DIR_U3D_SDK)\Source\RTL\Build\All\Release\WildCards\wildcards.lib"

    I'm at a bit of a loss to explain what's going on, but I can make a guess.  As indicated above IFXCore.lib has been replaced by IFXCoreStatic.lib.   Based solely on the difference in name I'm assuming these two differ in the way the core is loaded.  Since our issue related to an unload problem when shutting down the process, that would make sense. 

    I'm rather surprise that I'm able to link against either collection of libraries without changing any of our source code, but I think of ways where the libraries could be architected to make that possible.

    Perhaps someone with a better understanding of the code could comment on exactly what is happening differently based on switching out the libraries, and how that change would enable the process to shut down correctly.

     

  • Michail Vidiassov

    Michail Vidiassov - 2010-09-01

    My guess is (I am no windows programmer and do not know what is .lib <-> .dll relationship, and also do not see your code)
    that by linking to IFXCore you made OS load IFXCore.dll for you when you were starting your program and try to unload it in the end. The Intel way is for IFXCoreStatic to explicitly load IFXCore.dll and explicitly unload it (it is not a dynamic library but a dynamic module). May be you have got some mixture of the two approaches - IFXCore was loaded twice (implicitly as a library you have linked against and explicitly by code that normally goes to IFXCoreStatic but was obtained by you directly from the smaller libraries) and also unloaded twice. Had some problem like that on Linux.

    BTW, did you try to remove all but IFXCoreStatic.lib in your "Link libraries" list?

     

  • henry

    henry - 2010-09-02

    With regard to removing all but IFXCoreStatic.lib, I tried, but the listed set was the minimum I could achieve without getting unresolved externals.    From my experience, unless you have a detailed understanding of the code you are linking against, getting the correct set of lib's to link against can be a hit and miss experience.  Regardless, everything appears to be working at the moment.  Thanks for the help.

     

Log in to post a comment.