http://d.puremagic.com/issues/show_bug.cgi?id=6014



--- Comment #10 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-07-15 05:49:10 PDT ---
So here is what I can learn from this information:

1. The crash is happening on the final collection cycle when the runtime is
shutting down.
2. The memory block (pointer value 0x7ffff729d000) is marked as having a
finalizer.
3. The memory block being collected does not have a valid classinfo pointer
(which resides at the very beginning of the block), which means either:

  a. It's not really a class, and is incorrectly marked as having a finalizer
or
  b. The pointer has somehow been corrupted.

The issue with a problem like this is, the corruption could happen anywhere.

Given that dtors allocating memory has now been disallowed by 2.054 (a known cause of corruption), I don't think your code could be doing that.

So that leaves examining your code for incorrect memory operations.  I don't really have time to look through your code, but I'd recommend looking suspiciously at things where casts are used, or where you are using raw pointers.

One other thing is to add (or uncomment) some druntime debug printf statements -- print out the classinfo name and addresses for memory blocks being allocated.  That at least should tell you what the *original* type was being allocated for the failed memory block.  Sometimes this is the only way to debug such corruption issues.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6014



--- Comment #11 from changlon <changlon@gmail.com> 2011-07-17 19:39:01 PDT ---
I do not understand the mechanism of druntime ， this problem has troubled me for a long time .

According to my simple understanding, the following code does not cover up the failure， But in fact it failed. Is I got it wrong or druntime has a bug?

------------------------------------------------------
import core.memory;
void main(){
        auto attr = cast(GC.BlkAttr) 0b1 ;
        auto test = GC.malloc(10, attr);
        GC.setAttr(test, 0);
        auto _attr = GC.getAttr(test);
        assert(attr != _attr);
}
-----------------------------------------------------

I use GC.malloc and  GC.realloc to speed up the memory alloc,  A memory block attr has be changed before exit main function .

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6014



--- Comment #12 from changlon <changlon@gmail.com> 2011-08-08 19:46:06 PDT ---
I think the bug is not because class cast .

in the code i have Token and ASTNode,  The Token is struct and ASTNode is class. if I apply them both on heap then it working fine,  if I only apply ASTNode on heap the problem is still there ,  If I apply only Token on heap the test is work fine .

I storage the pointer of Token struct on a global pointer, and print it before exit main function,  find it is diffent ,  that mean the Pool.data has been moved ,  and after exit main I got a  Segmentation .


I simply do nothing but just change the struct Token to class Token,  they still apply on pool but not heap,  The problem is not exists anymore.


So,  I guess this is not a cast(class) issue,  It is a struct issue, and
related with druntime GC .


the Segmentation is very rare, If i change a lite things on example.jade, the Segmentation will not exists .


If i apply stuct Token on heap the performance will be very bad,  It will cause 100 times than not apply on heap .



After several months of debug and test,  I finally resolved this problem . Thanks a lot for Steven Schveighoffer help .


my problem is not exists by switch stuck Token to class Token,  But I believe there is also a hidden an druntime GC bug,  So I will not close this bug .

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6014



--- Comment #13 from changlon <changlon@gmail.com> 2011-08-08 19:57:26 PDT ---
The struct implement with issue test case : http://gool.googlecode.com/files/jade_dtor_bug.tar.bz2

the class implement without issue test case : http://gool.googlecode.com/files/jade_dtor_bug_fixed.tar.bz2


I realy can't reduce the test case,  because it is a runtime issue .

jade is a web view template compiler, like http://www.smarty.net/ for php . jade will convert jade template language to d source for web deveplop purpose.

the hark part is if i change any jade view template source ( example.jade) the isuse will not exists, so I really do not know how to reduce this test case .

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6014


David Simcha <dsimcha@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsimcha@yahoo.com


--- Comment #14 from David Simcha <dsimcha@yahoo.com> 2011-08-13 13:09:09 PDT ---
FWIW this is where/how/why the sporadic segfaults in the std.parallelism unittests on Linux and FreeBSD that the auto tester keeps flagging are occurring.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6014



--- Comment #16 from Don <clugdbug@yahoo.com.au> 2011-09-06 01:24:59 PDT ---
*** Issue 5766 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6014


dawg@dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dawg@dawgfoto.de


--- Comment #17 from dawg@dawgfoto.de 2011-09-13 17:13:13 PDT ---
It could as well be a double finalization.
The vtable pointer is cleared when calling rt_finalize on a class.

There is also a deterministic bug happening due to an oversight in the finalization design. Finalization is done in memory order and does not take hierarchies into account.

---
class A
{
    ~this() {}
    void cleanup() {}
}

class B
{
    this(A a) { this.a = a; }
    ~this() { a.cleanup(); }
    A a;
}

void main() {
    auto a = new A();
    auto b = new B(a);
    // allocating a at a lower address than b causes it to be finalized earlier
    assert(cast(void*)b.a < cast(void*)b);
}
---

When b.a is finalized before b it's vtable is set to null, hence the segfault at accessing the classinfo.

It seems like we need to somehow sort the to be finalized memory while
scanning.
Any cheap ideas to do that are welcome.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6014


dawg@dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


--- Comment #18 from dawg@dawgfoto.de 2011-09-13 17:52:15 PDT ---
@changlon

You won't like the cause of your bug.
All fields in a struct are default initialized.
Pointers with null, Integrals with 0, Floats with NaN and enums with
the first enum member.

enum BlkAttr : uint
{
    FINALIZE    = 0b0000_0001, /// Finalize the data in this block on collect.
    NO_SCAN     = 0b0000_0010, /// Do not scan through this block on collect.
    NO_MOVE     = 0b0000_0100,  /// Do not move this memory block on collect.
    APPENDABLE  = 0b0000_1000, /// This block contains the info to allow
appending.
    NO_INTERIOR = 0b0001_0000
}

That means the attr flag in your memory pool is always set to BlkAttr.FINALIZE.
Every GC.malloc you do will get a wrong finalization.
It can be avoided this by giving a default value to the field.
GC.BlkAttr attr = cast(GC.BlkAttr)0;
Arguably this could be the default member in BlkAttr.

I will close this bug and open a new one for the order of class finalization.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6014



--- Comment #19 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-09-14 05:22:43 PDT ---
(In reply to comment #17)

> There is also a deterministic bug happening due to an oversight in the finalization design. Finalization is done in memory order and does not take hierarchies into account.

Just to clarify as you discovered in your new bug report, this is by design -- a destructor cannot rely on any heap-allocated data being present.

A concept in many GC-based languages is to have two "destructors", one which is only ever called synchronously, and one that can be called asynchronously by the GC.  The synchronous one always calls the asynchronous one.  This is sometimes called a finalizer (and in fact, ~this is a finalizer).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6014



--- Comment #20 from Sean Kelly <sean@invisibleduck.org> 2011-09-14 13:51:11 PDT ---
I've added BlkAttr.NONE as a default for this enum.  Seems like an easy way to avoid weird errors like this.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------