Getting compiler stack overflow when building my project, but still do not know how to localize piece of code that triggers this bug. Maybe this bug is already registered in bugzilla or someone could give some advice where to dig into?

Just runed building under gdb and got the following stack trace:

#149490 0x000000000056b79a in AliasDeclaration::overloadInsert(Dsymbol*) ()
#149491 0x000000000056be85 in OverDeclaration::overloadInsert(Dsymbol*) ()
#149492 0x000000000056b79a in AliasDeclaration::overloadInsert(Dsymbol*) ()
#149493 0x000000000056be85 in OverDeclaration::overloadInsert(Dsymbol*) ()
#149494 0x000000000056b79a in AliasDeclaration::overloadInsert(Dsymbol*) ()
#149495 0x000000000056be85 in OverDeclaration::overloadInsert(Dsymbol*) ()
#149496 0x000000000056b79a in AliasDeclaration::overloadInsert(Dsymbol*) ()
#149497 0x000000000056be85 in OverDeclaration::overloadInsert(Dsymbol*) ()
#149498 0x000000000056b79a in AliasDeclaration::overloadInsert(Dsymbol*) ()
#149499 0x000000000056be85 in OverDeclaration::overloadInsert(Dsymbol*) ()
#149500 0x000000000056b79a in AliasDeclaration::overloadInsert(Dsymbol*) ()
#149501 0x000000000056be85 in OverDeclaration::overloadInsert(Dsymbol*) ()
#149502 0x000000000056b79a in AliasDeclaration::overloadInsert(Dsymbol*) ()
#149503 0x00000000005ce05a in dmd.dsymbolsem.aliasSemantic(dmd.declaration.AliasDeclaration, dmd.dscope.Scope*) ()
#149504 0x00000000005b5adc in DsymbolSemanticVisitor::visit(AliasDeclaration*) ()
#149505 0x000000000056bc99 in AliasDeclaration::accept(Visitor*) ()
#149506 0x00000000005b9df0 in DsymbolSemanticVisitor::visit(Import*) ()
#149507 0x0000000000570e7a in Import::accept(Visitor*) ()
#149508 0x00000000005bcd24 in DsymbolSemanticVisitor::visit(Module*) ()
#149509 0x0000000000594785 in Module::accept(Visitor*) ()
#149510 0x00000000005b9b5f in DsymbolSemanticVisitor::visit(Import*) ()
#149511 0x0000000000570e7a in Import::accept(Visitor*) ()
#149512 0x00000000005bae7f in DsymbolSemanticVisitor::attribSemantic(AttribDeclaration*) ()
#149513 0x00000000005baf9d in DsymbolSemanticVisitor::visit(AttribDeclaration*) ()
#149514 0x000000000070510f in ParseTimeVisitor<ASTCodegen>::visit(ProtDeclaration*) ()
#149515 0x0000000000528b21 in ProtDeclaration::accept(Visitor*) ()
#149516 0x00000000005bcd24 in DsymbolSemanticVisitor::visit(Module*) ()
#149517 0x0000000000594785 in Module::accept(Visitor*) ()
#149518 0x000000000068f8f9 in dmd.mars.tryMain(ulong, const(char)**) ()
#149519 0x000000000069116b in D main ()

On Sunday, 4 February 2018 at 12:52:22 UTC, Ur@nuz wrote:
> Getting compiler stack overflow when building my project, but still do not know how to localize piece of code that triggers this bug. Maybe this bug is already registered in bugzilla or someone could give some advice where to dig into?
>
> [...]

You'll have to post the code if you want people to be able to reproduce things.
I believe the the dustmite tool should have an obfuscate mode, if you cannot share a clear version of it.

On Sunday, February 04, 2018 13:54:17 Stefan Koch via Digitalmars-d-learn wrote:
> On Sunday, 4 February 2018 at 12:52:22 UTC, Ur@nuz wrote:
> > Getting compiler stack overflow when building my project, but still do not know how to localize piece of code that triggers this bug. Maybe this bug is already registered in bugzilla or someone could give some advice where to dig into?
> >
> > [...]
>
> You'll have to post the code if you want people to be able to
> reproduce things.
> I believe the the dustmite tool should have an obfuscate mode, if
> you cannot share a clear version of it.

It does, though if you give it a large piece of code, odds are that it'll make your program so unrecognizable that it won't matter.

- Jonathan M Davis

On Sun, Feb 04, 2018 at 12:52:22PM +0000, Ur@nuz via Digitalmars-d-learn wrote:
> Getting compiler stack overflow when building my project, but still do not know how to localize piece of code that triggers this bug. Maybe this bug is already registered in bugzilla or someone could give some advice where to dig into?
> 
> Just runed building under gdb and got the following stack trace:
[...]

I'm not 100% familiar with the dmd code, but here's my guess as to the approximate location of the problem, based on looking at the stack trace:

- It's probably inside a protection declaration, perhaps something like
  `private { ... }` or `protected { ... }` or something along those
  lines.

- There appears to be an import statement somewhere in there, that
  appears to lead to another module with another import;

- Eventually, it ends in what looks like a recursive alias to an
  overload that appears to be in a loop, which is likely the cause of
  the compiler crash.

So my wild guess is that there's probably an alias (or multiple aliases) somewhere in your code that brings in a symbol into an overload set, and somehow these aliases are referring to each other in a loop. Quite likely this alias resides in a module imported by another module, which in turn is imported from within the protection block.

Don't know if this helps, but hopefully it narrows down the problem somewhat.


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG

On 2018-02-04 13:52, Ur@nuz wrote:
> Getting compiler stack overflow when building my project, but still do not know how to localize piece of code that triggers this bug. Maybe this bug is already registered in bugzilla or someone could give some advice where to dig into?
> 
> Just runed building under gdb and got the following stack trace:

Sharing your code (if possible) would help. Building the compiler with debug symbols ("make -f posix.mak DEBUG=1") would help to give file and line info in the stack trace.

-- 
/Jacob Carlborg

On Monday, 5 February 2018 at 12:20:05 UTC, Jacob Carlborg wrote:
> On 2018-02-04 13:52, Ur@nuz wrote:
>> Getting compiler stack overflow when building my project, but still do not know how to localize piece of code that triggers this bug. Maybe this bug is already registered in bugzilla or someone could give some advice where to dig into?
>> 
>> Just runed building under gdb and got the following stack trace:
>
> Sharing your code (if possible) would help. Building the compiler with debug symbols ("make -f posix.mak DEBUG=1") would help to give file and line info in the stack trace.

I have failed to figure out the source of bug. Seems that my code is incorrect somewhere, but compiler crash instead of writing some error...

If someone wants to dig into I fixed branch with error in my repository "epic_fail123". My code is not on code.dlang.org yet...
1. git clone https://github.com/uranuz/ivy
2. hg clone https://bitbucket.org/uranuz/webtank (Yes it is Mercurial)
3. switch to "webtank" branch "epic_fail123"
4. cd <webtank-root>
5. dub add-local <ivy-root>
6. dub build --config=with_ivy

Build may require some dependencies: libpq (PostgreSQL) and openssl.
But b/c it fails on compilation you may not need it..

On Mon, Feb 05, 2018 at 07:30:09PM +0000, Ur@nuz via Digitalmars-d-learn wrote:
> On Monday, 5 February 2018 at 12:20:05 UTC, Jacob Carlborg wrote:
> > On 2018-02-04 13:52, Ur@nuz wrote:
> > > Getting compiler stack overflow when building my project, but still do not know how to localize piece of code that triggers this bug.  Maybe this bug is already registered in bugzilla or someone could give some advice where to dig into?
> > > 
> > > Just runed building under gdb and got the following stack trace:
> > 
> > Sharing your code (if possible) would help. Building the compiler
> > with debug symbols ("make -f posix.mak DEBUG=1") would help to give
> > file and line info in the stack trace.
> 
> I have failed to figure out the source of bug. Seems that my code is incorrect somewhere, but compiler crash instead of writing some error...
[...]

The compiler should never crash, no matter how bad the input code. An internal compiler error is always a compiler bug, and a bug report should be filed. (Though it's probably better to have actual code that can reproduce the problem, otherwise it will be hard to do anything about the bug.)


T

-- 
IBM = I Blame Microsoft