HD91968: PROBLEM WHEN UNLOADING A CAA DLL FROM A PROCESS

APAR status

• Closed as documentation error.

Error description

• Procedure to trigger the problem:
  .
  - add your B19 (win32) "bin" directory to your PATH
  environment variable. This is required because our
  CATIAModeler.dll has to find the CATIA dlls (dependencies)
  - go to CAA_Support\Fake\CATIAModeler\intel_a\code\bin. You
  will find in this directory our test application
  (Application.exe) and two dlls. RealCATIAModeler.dll is the
  dll with the problem. FakeCATIAModeler.dll is a very very
  simpler version that does not have the problem.
  - run the Application.exe program from mkrun environment from
  command prompt
  - select "Use RealCATIAModeler.dll" option
  - click on "Load CATIAModeler.dll" button then wait while the
  RealCATIAModeler.dll is loading
  - click on "Unload CATIAModeler.dll" (*)
  - click again on "Load CATIAModeler.dll" => an error and a
  crash should occur
  - restart the Application.exe program
  - do the same steps but using "Use FakeCATIAModeler.dll"
  option instead. No crash will occur. Note: FakeCATIAModel.dll
  does not have same CATIA dlls dependencies because there is
  no useful CAA code inside it.
  .
  Even if you wait for some (long) time. From our point of
  view, this is not a normal behavior
  .
  This is the problem and this is the reason why this crashes
  when we load again our RealCATIAModeler.dll
  .
  FYI, No CAA code is executed when we load/unload the
  RealCATIAModeler.dll using LoadLibrary/FreeLibrary APIs. Also
  we don't have any global / static variable, we don't start
  any new worker thread in our code and don't use
  WaitForSingleObject() and so on... (no mutex, no ciritical
  section etc...).
  .
  We observe this problem from R13 to R19 (win32 or win64)
  using latest available service pack for each CATIA release
  

Local fix

• empty
  

Problem summary

• Procedure to trigger the problem:
  .
  - add your B19 (win32) "bin" directory to your PATH
  environment variable. This is required because our
  CATIAModeler.dll has to find the CATIA dlls (dependencies)
  - go to CAA_Support\Fake\CATIAModeler\intel_a\code\bin. You
  will find in this directory our test application
  (Application.exe) and two dlls. RealCATIAModeler.dll is the
  dll with the problem. FakeCATIAModeler.dll is a very very
  simpler version that does not have the problem.
  - run the Application.exe program from mkrun environment from
  command prompt
  - select "Use RealCATIAModeler.dll" option
  - click on "Load CATIAModeler.dll" button then wait while the
  RealCATIAModeler.dll is loading
  - click on "Unload CATIAModeler.dll" (*)
  - click again on "Load CATIAModeler.dll" => an error and a
  crash should occur
  - restart the Application.exe program
  - do the same steps but using "Use FakeCATIAModeler.dll"
  option instead. No crash will occur. Note: FakeCATIAModel.dll
  does not have same CATIA dlls dependencies because there is
  no useful CAA code inside it.
  .
  Even if you wait for some (long) time. From our point of
  view, this is not a normal behavior
  .
  This is the problem and this is the reason why this crashes
  when we load again our RealCATIAModeler.dll
  .
  FYI, No CAA code is executed when we load/unload the
  RealCATIAModeler.dll using LoadLibrary/FreeLibrary APIs. Also
  we don't have any global / static variable, we don't start
  any new worker thread in our code and don't use
  WaitForSingleObject() and so on... (no mutex, no ciritical
  section etc...).
  .
  We observe this problem from R13 to R19 (win32 or win64)
  using latest available service pack for each CATIA release
  

Problem conclusion

• THIS MODIFICATION WILL BE INCLUDED IN THE DOCUMENTATION
  DELIVERED WITH VERSION V5R21
  Additional Closure Information:
  Manual Reference:
  CAA Encyclopedia - Multi-Workspace Application Builder
  Topic: FAQ
  Documentation after correction :
  Why Should I Avoid Unloading and Loading Modules?
  Unloading a DLL while CATIA is running, and then reloading it
  is technically possible thanks to some system calls.
  Nevertheless, this may lead to unpredictable results such as
  memory corruptions, memory leaks, or even process crashes.
  This may happen because the unloaded DLL is reloaded at a
  different memory address. All the dynamic bindings set, for
  example, through QueryInterface, before the DLL unload and
  that might be held by objects in the other DLLs will now
  point to invalid addresses where no DLL is mapped any longer.
  When these objects are used, the application cannot thus
  behave as expected.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels