Is this a bug?

Mike Parker via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sun May 4 03:28:30 PDT 2014


On 5/4/2014 6:42 PM, Alex wrote:
> Hello,
>
> I am trying to use the std.log module that is here:
>
> https://github.com/linkrope/log.d
>
> And I encountered a segmentation fault using dmd 2.065 on a Linux 64
> platform. The reduced test case is this:
>
> //============================================================================
>
> import std.stdio;
> import std.log;
>
> private class CHello {
>
>      ~this() {
>          info("info - destructor"); //info, warning, error segfault;
> however, writefln works
>      }
> }
>
> void main(string[] args) { CHello chello = new CHello(); }
> //============================================================================
>
>
> Is this a bug?

No, it is not a bug. It's a hazard of destructors in D.

Because of the GC, there are certain things you cannot rely on when it 
comes to destruction. One is that there is no guarantee that the 
destructor will ever be called during the lifetime of the app. The 
second, and likely the problem you're seeing, is that you cannot rely on 
the order of destruction.

If you look at the source for std.log, you'll see that info() ultimately 
(via some templating) maps to an instance of LogFilter, which is a class 
allocated on the GC heap in a module constructor. When the app exits, 
one of the last things DRuntime does is to terminate the GC (see rt_term 
in dmain2.d in the DRuntime source). The current implementation of the 
GC will run destructors on any objects still resident on the heap during 
termination. There is no way to guarantee the order in which those 
destructors will be run.

Most likely, what you're seeing is that the LogFilter instance 
referenced by the info template is being destroyed before the destructor 
on CHello is run. Therefore, you're referencing an invalid memory location.

The short of it is that you should never touch anything on that lives on 
the GC heap from inside a destructor -- there's no guarantee that it 
will still be alive when your destructor is run.


More information about the Digitalmars-d-learn mailing list