www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Getting compiler Segfault

reply Ur nuz <neuranuz yandex.ru> writes:
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 ()
Feb 04
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Feb 04
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Feb 04
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Feb 04
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Feb 05
parent reply Ur nuz <neuranuz yandex.ru> writes:
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..
Feb 05
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Feb 06