digitalmars.D.learn - Getting compiler Segfault
- Ur nuz (60/60) Feb 04 2018 Getting compiler stack overflow when building my project, but
- Stefan Koch (5/10) Feb 04 2018 You'll have to post the code if you want people to be able to
- Jonathan M Davis (5/16) Feb 04 2018 It does, though if you give it a large piece of code, odds are that it'l...
- H. S. Teoh (24/30) Feb 04 2018 [...]
- Jacob Carlborg (6/12) Feb 05 2018 Sharing your code (if possible) would help. Building the compiler with
- Ur nuz (16/27) Feb 05 2018 I have failed to figure out the source of bug. Seems that my code
- H. S. Teoh (10/26) Feb 06 2018 [...]
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: AliasDeclaration::overloadInsert(Dsymbol*) () OverDeclaration::overloadInsert(Dsymbol*) () AliasDeclaration::overloadInsert(Dsymbol*) () OverDeclaration::overloadInsert(Dsymbol*) () AliasDeclaration::overloadInsert(Dsymbol*) () OverDeclaration::overloadInsert(Dsymbol*) () AliasDeclaration::overloadInsert(Dsymbol*) () OverDeclaration::overloadInsert(Dsymbol*) () AliasDeclaration::overloadInsert(Dsymbol*) () OverDeclaration::overloadInsert(Dsymbol*) () AliasDeclaration::overloadInsert(Dsymbol*) () OverDeclaration::overloadInsert(Dsymbol*) () AliasDeclaration::overloadInsert(Dsymbol*) () dmd.dsymbolsem.aliasSemantic(dmd.declaration.AliasDeclaration, dmd.dscope.Scope*) () DsymbolSemanticVisitor::visit(AliasDeclaration*) () () DsymbolSemanticVisitor::visit(Import*) () DsymbolSemanticVisitor::visit(Module*) () DsymbolSemanticVisitor::visit(Import*) () DsymbolSemanticVisitor::attribSemantic(AttribDeclaration*) () DsymbolSemanticVisitor::visit(AttribDeclaration*) () ParseTimeVisitor<ASTCodegen>::visit(ProtDeclaration*) () DsymbolSemanticVisitor::visit(Module*) () const(char)**) ()
Feb 04 2018
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 2018
Jonathan M Davis <newsgroup.d jmdavisprog.com> 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: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 DavisGetting 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 2018
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 2018
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 2018
On Monday, 5 February 2018 at 12:20:05 UTC, Jacob Carlborg wrote:On 2018-02-04 13:52, Ur nuz wrote: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..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.
Feb 05 2018
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:[...] 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 MicrosoftOn 2018-02-04 13:52, Ur nuz wrote: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...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.
Feb 06 2018