www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Segfault when adding a static destructor in

reply RazvanN <razvan.nitu1305 gmail.com> writes:
Hi all,

I am working on issue 14650 [1] and I would like to implement a 
solution where static destructors are destroying global 
variables. However, I have the following problem in 
druntime/src/rt/sections_elf_shared:

struct ThreadDSO
{
     DSO* _pdso;
     static if (_pdso.sizeof == 8) uint _refCnt, _addCnt;
     else static if (_pdso.sizeof == 4) ushort _refCnt, _addCnt;
     else static assert(0, "unimplemented");
     void[] _tlsRange;
     alias _pdso this;
     // update the _tlsRange for the executing thread
     void updateTLSRange() nothrow  nogc
     {
         _tlsRange = _pdso.tlsRange();
     }
}
Array!(ThreadDSO) _loadedDSOs;


For this code, I would have to create the following static 
destructor:

static ~this() { _loadedDSOs.__dtor(); }

Because Array defines a destructor which sets its length to 0.

However this code leads to segfault when compiling any program 
with the runtime (betterC code compiles successfully). In my 
attempt to debug it, I dropped my patch and added the above 
mentioned static destructor manually in druntime which lead to 
the same effect. Interestingly, _loadedDSOs.__dtor runs 
successfully, the segmentation fault comes from somewhere higher 
in the call path (outside of the _d_run_main function (in 
rt/dmain2.d)). I'm thinking that the static destructor somehow 
screws up the object which is later referenced after the main 
program finished executing. Does someone well versed in druntime 
has any ideas what's happening?

Cheers,
RazvanN



[1] https://issues.dlang.org/show_bug.cgi?id=14650
Jan 08
next sibling parent reply Johan Engelen <j j.nl> writes:
On Tuesday, 8 January 2019 at 12:54:11 UTC, RazvanN wrote:
 Hi all,

 I am working on issue 14650 [1]
Great! (I am _extremely_ surprised that dtors are not called for globals.) and I would like to implement a
 solution where static destructors are destroying global 
 variables. However, I have the following problem in 
 druntime/src/rt/sections_elf_shared:

 struct ThreadDSO
 {
     DSO* _pdso;
     static if (_pdso.sizeof == 8) uint _refCnt, _addCnt;
     else static if (_pdso.sizeof == 4) ushort _refCnt, _addCnt;
     else static assert(0, "unimplemented");
     void[] _tlsRange;
     alias _pdso this;
     // update the _tlsRange for the executing thread
     void updateTLSRange() nothrow  nogc
     {
         _tlsRange = _pdso.tlsRange();
     }
 }
 Array!(ThreadDSO) _loadedDSOs;


 For this code, I would have to create the following static 
 destructor:

 static ~this() { _loadedDSOs.__dtor(); }

 Because Array defines a destructor which sets its length to 0.

 However this code leads to segfault when compiling any program 
 with the runtime (betterC code compiles successfully). In my 
 attempt to debug it, I dropped my patch and added the above 
 mentioned static destructor manually in druntime which lead to 
 the same effect. Interestingly, _loadedDSOs.__dtor runs 
 successfully, the segmentation fault comes from somewhere 
 higher in the call path (outside of the _d_run_main function 
 (in rt/dmain2.d)). I'm thinking that the static destructor 
 somehow screws up the object which is later referenced after 
 the main program finished executing. Does someone well versed 
 in druntime has any ideas what's happening?
This is my guess: Have a look at `_d_dso_registry` and it's description. The function is also called upon shutdown and it accesses `_loadedDSOs`. As part of shutdown, `_d_dso_registry` calls `runModuleDestructors` (which will run your compiler-inserted static dtor), but _after_ that `_d_dso_registry` accesses `_loadedDSOs`. I don't know exactly why the segfault happens, but the code assumes in several places that `_loadedDSOs` is non-empty. For example, `popBack` is called and `popBack` is invalid for length=0 (it will set the length to `size_t.max` !). I think the solution is to not have `_loadedDSOs` be of type `Array!T` but of a special type that explicitly has no dtor (i.e. the "dtor" should only be called explicitly such that the data needed for shutdown survives `runModuleDestructors`). This probably applies to more of these druntime low-level arrays and other data structures. -Johan [1] The dtor of Array calls reset, and reset has a bug in rt.util.container.Array. Note the invariant: `assert(!_ptr == !_length);`, which triggers when `_length` is set to 0, but `_ptr` is not set to `null`. !!!
Jan 08
parent RazvanN <razvan.nitu1305 gmail.com> writes:
On Tuesday, 8 January 2019 at 14:30:24 UTC, Johan Engelen wrote:
 On Tuesday, 8 January 2019 at 12:54:11 UTC, RazvanN wrote:
 [...]
Great! (I am _extremely_ surprised that dtors are not called for globals.) [...]
Thanks! This is really helpful! RazvanN
Jan 10
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/8/19 7:54 AM, RazvanN wrote:
 Hi all,
 
 I am working on issue 14650 [1] and I would like to implement a solution 
 where static destructors are destroying global variables. However, I 
 have the following problem in druntime/src/rt/sections_elf_shared:
 
 struct ThreadDSO
 {
      DSO* _pdso;
      static if (_pdso.sizeof == 8) uint _refCnt, _addCnt;
      else static if (_pdso.sizeof == 4) ushort _refCnt, _addCnt;
      else static assert(0, "unimplemented");
      void[] _tlsRange;
      alias _pdso this;
      // update the _tlsRange for the executing thread
      void updateTLSRange() nothrow  nogc
      {
          _tlsRange = _pdso.tlsRange();
      }
 }
 Array!(ThreadDSO) _loadedDSOs;
 
 
 For this code, I would have to create the following static destructor:
 
 static ~this() { _loadedDSOs.__dtor(); }
 
 Because Array defines a destructor which sets its length to 0.
 
 However this code leads to segfault when compiling any program with the 
 runtime (betterC code compiles successfully). In my attempt to debug it, 
 I dropped my patch and added the above mentioned static destructor 
 manually in druntime which lead to the same effect. Interestingly, 
 _loadedDSOs.__dtor runs successfully, the segmentation fault comes from 
 somewhere higher in the call path (outside of the _d_run_main function 
 (in rt/dmain2.d)). I'm thinking that the static destructor somehow 
 screws up the object which is later referenced after the main program 
 finished executing. Does someone well versed in druntime has any ideas 
 what's happening?
That is a thread-local static destructor. Are any shared static destructors accessing the array? You might be able to determine this by printf debugging between calling unshared and shared destructors. -Steve
Jan 10
parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
On Thursday, 10 January 2019 at 15:04:25 UTC, Steven 
Schveighoffer wrote:
 On 1/8/19 7:54 AM, RazvanN wrote:
 [...]
That is a thread-local static destructor. Are any shared static destructors accessing the array?
No, there aren't. Indeed, the problem is as Johan as said: the loadedDSOs should not be wrapped in an array with a destructor because it is manually destroyed.
 You might be able to determine this by printf debugging between 
 calling unshared and shared destructors.

 -Steve
Jan 10
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/10/19 5:12 PM, RazvanN wrote:
 On Thursday, 10 January 2019 at 15:04:25 UTC, Steven Schveighoffer wrote:
 On 1/8/19 7:54 AM, RazvanN wrote:
 [...]
That is a thread-local static destructor. Are any shared static destructors accessing the array?
No, there aren't. Indeed, the problem is as Johan as said: the loadedDSOs should not be wrapped in an array with a destructor because it is manually destroyed.
Hm... is this a sign of how things will be once the (necessary IMO) change to destroying globals is deployed? -Steve
Jan 10
parent RazvanN <razvan.nitu1305 gmail.com> writes:
On Thursday, 10 January 2019 at 23:04:37 UTC, Steven 
Schveighoffer wrote:
 On 1/10/19 5:12 PM, RazvanN wrote:
 On Thursday, 10 January 2019 at 15:04:25 UTC, Steven 
 Schveighoffer wrote:
 On 1/8/19 7:54 AM, RazvanN wrote:
 [...]
That is a thread-local static destructor. Are any shared static destructors accessing the array?
No, there aren't. Indeed, the problem is as Johan as said: the loadedDSOs should not be wrapped in an array with a destructor because it is manually destroyed.
Hm... is this a sign of how things will be once the (necessary IMO) change to destroying globals is deployed? -Steve
At least for this specific situation, yes.
Jan 11