[Openmp-commits] [PATCH] D94256: [OpenMP] Fixed the issue that memory manager calls plugin interface to release buffered memory even after the plugin has been destroyed

[Vyacheslav Zakharin via Phabricator via Openmp-commits]

vzakhari added inline comments.


================
Comment at: openmp/libomptarget/src/rtl.cpp:444-445
 
   // TODO: Remove RTL and the devices it manages if it's not used anymore?
   // TODO: Write some RTL->unload_image(...) function?
 
----------------
tianshilei1992 wrote:
> vzakhari wrote:
> > tianshilei1992 wrote:
> > > vzakhari wrote:
> > > > Can we just implement this instead?
> > > At this point, the plugin has already been destroyed.
> > How is that possible, since we never call dlclose() for the plugins?
> > Is the problem specific to some particular execution conditions?
> > 
> > Should we just "deinitialize" the memory manager here instead of postponing the "deinitialization" to MemoryManagerTy desctructor, which will obviously be executed at the wrong time.
> That's most tough part of this question. `libomptarget` has no idea when its opened plugin will be destroyed. Actually, you can see there is no `dlclose` in current code. What we can know is, plugin will be destroyed before `libomptarget`. You can easily verify it by adding `DP(...)` to the destructor of the plugin.
This sounds really strange at least for Linux, since:
> The dynamic linker maintains reference counts for object handles, so a dynamically loaded shared object is not deallocated until dlclose() has been called on it as many times as dlopen() has succeeded on it. 

Do you have a reproducer for this kind of an issue?  I must be missing something here...




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94256/new/

https://reviews.llvm.org/D94256