Segfault at the end of the program when using dlclose()

My program loads plugins at runtime by means of dlopen/dlclose. I get a segfault at the end of the program with this stack trace:

This happens because of the calls to dlclose: if I don’t close the opened plugins then the crash does not happen. Moreover, it happens only when plugins are loaded in a given order. This issue seems to be the same as described in this forum post. The only workaround they seem to have found is to not call dlclose, but I’d not call it a satisfactory one…
Has anyone any suggestion about this issue? Thanks.

Hi,

Do you have a running program reproducing this crash ? Otherwise it os difficult to understand what is the origin

Lorenzo

Hi Lorenzo, my program experiencing the problem is too big and involved to be a nice example to showcase the issue. I’ll try to put together a demonstrator and post it back here when it’s ready (if it will ever be: this issue is quite erratic according to my early tests, and I’m not sure if I can reproduce it in a simple demonstrator).
Thanks.

I have not found the reason of the fault but I have found a solution. The segfault was generated by the automated garbage collection at the ed of the program. Specifically, I have a file which I close but I didn’t delete the TFile object. When gROOT’s destructor tried to delete it (fClosedObjects->Delete(“slow”) at line 506 of TROOT.cxx, down to G__resetglobalvar) the segfault happened. So I deleted the file object before unloading the plugins and the segfault vanished, replaced by a different one.

This time the segfault came from gSystem’s destructor, when deleting the file handlers (fFileHandler->Delete() at line 159 of TSystem.h, down to TCollection::GarbageCollect). The file handler whose destruction was causing the segfault is a TGInputHandler, I’m using a GUI in my program. Again, deleting all the handlers before unloading the plugins with:

TSeqCollection *c = gSystem->GetListOfFileHandlers(); for (int i = 0; i < c->GetEntries(); i++) { delete c->At(i); }

fixes the problem.

I really do not understand what’s going on, nor why loading plugins in a different order changes the behaviour of my program. The only suspect I have is that, since my plugin manager object is a static singleton on the stack which unloads the plugins in its destructor, the problem might be related to the undefined sequence of destruction of global stack objects at the end of the program. I am pretty confident that there were no double deletes or similars, but nevertheless an error was generated.

In case anyone else is hit by this issue my advice is to look for segfaults during automatic object destruction and then to try to delete the objects manually.