https://issues.dlang.org/show_bug.cgi?id=15272

ag0aep6g@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ag0aep6g@gmail.com

--- Comment #1 from ag0aep6g@gmail.com ---
(In reply to bb.temp from comment #0)
> So far I'm here but it doesn't capture the essence of the problem.
> 
> ---
[...]
> ---

That code segfaults for me. Is that what you see, too?

--

https://issues.dlang.org/show_bug.cgi?id=15272

--- Comment #2 from ag0aep6g@gmail.com ---
(In reply to bb.temp from comment #0)
> So far I'm here but it doesn't capture the essence of the problem.
> 
> ---
[...]
> ---

As far as I can tell, everything works as expected in that code.

The different `children` arrays are GC allocated (via ~=), but the `Foo`s themselves are not. So a parent `Foo` doesn't keep its `children` alive, and at some point the GC collects the seemingly dead arrays.

--

https://issues.dlang.org/show_bug.cgi?id=15272

--- Comment #3 from bb.temp@gmx.com ---
(In reply to ag0aep6g from comment #2)
> (In reply to bb.temp from comment #0)
> > So far I'm here but it doesn't capture the essence of the problem.
> > 
> > ---
> [...]
> > ---
> 
> As far as I can tell, everything works as expected in that code.
> 
> The different `children` arrays are GC allocated (via ~=), but the `Foo`s themselves are not. So a parent `Foo` doesn't keep its `children` alive, and at some point the GC collects the seemingly dead arrays.

Take care with the small sample. I've written that <<it does not reproduce the problem>>, it was just an attempt. So far it just helped to show that it's necessary to add the ranges to the GC, which I've done to the real program.

Despite of this in the real program it's still the same, if I call
'write(slb.serialize)':

- with '-inline': stdout is empty.
- without: stdout is filled

When you consider those two facts it really looks that the inliner does something wrong.

--

https://issues.dlang.org/show_bug.cgi?id=15272

--- Comment #4 from ag0aep6g@gmail.com ---
I think this is a bug in libdparse.

Its `StringCache` allocates space for `buckets`, but doesn't null the pointers. On destruction it then tries to `free` the garbage pointers in there.

https://github.com/Hackerpilot/libdparse/blob/8230f207912b40a46e5eae84e50ee59215b7c67f/src/dparse/lexer.d#L2009

Could you try adding `buckets[] = null;` after that line, then rebuild libdparse, and see if your project still crashes?

--

https://issues.dlang.org/show_bug.cgi?id=15272

--- Comment #5 from ag0aep6g@gmail.com ---
(In reply to ag0aep6g from comment #4)
> I think this is a bug in libdparse.
> 
> Its `StringCache` allocates space for `buckets`, but doesn't null the pointers. On destruction it then tries to `free` the garbage pointers in there.

Forget that. It's using calloc, not malloc, so it should be all zeros already.

--

https://issues.dlang.org/show_bug.cgi?id=15272

--- Comment #6 from bb.temp@gmx.com ---
(In reply to ag0aep6g from comment #4)
> I think this is a bug in libdparse.
> 
> Its `StringCache` allocates space for `buckets`, but doesn't null the pointers. On destruction it then tries to `free` the garbage pointers in there.
> 
> https://github.com/Hackerpilot/libdparse/blob/ 8230f207912b40a46e5eae84e50ee59215b7c67f/src/dparse/lexer.d#L2009
> 
> Could you try adding `buckets[] = null;` after that line, then rebuild libdparse, and see if your project still crashes?

Yes. I confirm that the fix you suggested in libdparse works.

But now I don't know whom the bug belongs to...
Was it accidental that the program worked without -inline and without the
libdparse fix ?!

--

https://issues.dlang.org/show_bug.cgi?id=15272

--- Comment #7 from ag0aep6g@gmail.com ---
Here's a reduction that segfaults reliably for me with -release -O -inline:
----
extern(C) void* calloc(size_t, size_t) nothrow pure;

void main()
{
    {
        File file_;
        nop();
    }

    auto scache = StringCache(1);
    foreach (nodePointer; scache.buckets)
    {
        if (nodePointer !is null) new Object;
    }
}

struct File
{
    ~this() {}
}

void nop() {}

struct StringCache
{
    this(size_t bucketCount)
    {
        buckets = (cast(void**) calloc(8, bucketCount))[0 .. bucketCount];
    }

    void*[] buckets;
}
----

(In reply to bb.temp from comment #6)
> Yes. I confirm that the fix you suggested in libdparse works.
> 
> But now I don't know whom the bug belongs to...
> Was it accidental that the program worked without -inline and without the
> libdparse fix ?!

I was mistaken. The bug I saw in libdparse is not there. My "fix" probably just masks the issue somehow.

--

https://issues.dlang.org/show_bug.cgi?id=15272

--- Comment #8 from bb.temp@gmx.com ---
(In reply to ag0aep6g from comment #7)
> Here's a reduction that segfaults reliably for me with -release -O -inline:
> ----
> extern(C) void* calloc(size_t, size_t) nothrow pure;
> 
> void main()
> {
>     {
>         File file_;
>         nop();
>     }
> 
>     auto scache = StringCache(1);
>     foreach (nodePointer; scache.buckets)
>     {
>         if (nodePointer !is null) new Object;
>     }
> }
> 
> struct File
> {
>     ~this() {}
> }
> 
> void nop() {}
> 
> struct StringCache
> {
>     this(size_t bucketCount)
>     {
>         buckets = (cast(void**) calloc(8, bucketCount))[0 .. bucketCount];
>     }
> 
>     void*[] buckets;
> }
> ----

Yes that's it. Thx much for your patience.

--

https://issues.dlang.org/show_bug.cgi?id=15272

bb.temp@gmx.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |regression

--

https://issues.dlang.org/show_bug.cgi?id=15272

Marc Schütz <schuetzm@gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schuetzm@gmx.net

--- Comment #9 from Marc Schütz <schuetzm@gmx.net> ---
Digger blames this PR for me: https://github.com/D-Programming-Language/dmd/pull/5060

... but this looks very unlikely to be the culprit.

--