Thread overview
Help with failing assert in dmd.backend.symbol.d
Sep 01, 2022
Teodor Dutu
Sep 01, 2022
Nicholas Wilson
Sep 02, 2022
max haughton
Sep 12, 2022
Teodor Dutu
September 01, 2022

Hi,

I have recently opened this PR to change _d_arraysetassign to a template. It has caused this builkite failure in vibe-d. I am able to reproduced it locally, but I am unable to debug it.

Being a backend error, the Symbol struct doesn't seem to store precise information about the line and file from where that symbol comes. I have used Symbol.lposscopestart, but that only tells where the symbol was created. In my case, it was created here: phobos/std/typecons.d(6822), but this doesn't provide me with too much info.

How would you debug this? Do you have any "tips" for debugging the backend? I'd also like to build vibe-d without dub so I can trace the compiler directly. How can I do this?

Thanks for the help,
Teodor

September 01, 2022

On Thursday, 1 September 2022 at 19:24:24 UTC, Teodor Dutu wrote:

>

Hi,

I have recently opened this PR to change _d_arraysetassign to a template. It has caused this builkite failure in vibe-d. I am able to reproduced it locally, but I am unable to debug it.

Being a backend error, the Symbol struct doesn't seem to store precise information about the line and file from where that symbol comes. I have used Symbol.lposscopestart, but that only tells where the symbol was created. In my case, it was created here: phobos/std/typecons.d(6822), but this doesn't provide me with too much info.

How would you debug this? Do you have any "tips" for debugging the backend? I'd also like to build vibe-d without dub so I can trace the compiler directly. How can I do this?

Thanks for the help,
Teodor

You should be able to run dub in verbose mode to spit out the compiler and linker invocations. From there, I'd recommend dust mite to create a minimal (or at least smaller) example. Then there are a bunch of hidden debug switches https://github.com/dlang/dmd/pull/14356 that may help.

September 02, 2022

On Thursday, 1 September 2022 at 19:24:24 UTC, Teodor Dutu wrote:

>

Hi,

I have recently opened this PR to change _d_arraysetassign to a template. It has caused this builkite failure in vibe-d. I am able to reproduced it locally, but I am unable to debug it.

Being a backend error, the Symbol struct doesn't seem to store precise information about the line and file from where that symbol comes. I have used Symbol.lposscopestart, but that only tells where the symbol was created. In my case, it was created here: phobos/std/typecons.d(6822), but this doesn't provide me with too much info.

How would you debug this? Do you have any "tips" for debugging the backend? I'd also like to build vibe-d without dub so I can trace the compiler directly. How can I do this?

Thanks for the help,
Teodor

Try running gdb in follow fork mode, or run dub in verbose mode to get the dmd command.

The backends knowledge of where things come from is terrible.

For debugging the backend if it's not an obvious segfault or memory corruption etc you better get lucky with a printf or you're out of luck. It's an old and horrible codebase, the trees are simple enough but the algorithms were mostly designed before anything resembling modern compiler design practice.

Feel free to ramble on the d slack about what you've tried so far.

September 12, 2022

On Friday, 2 September 2022 at 18:02:22 UTC, max haughton wrote:

>

Try running gdb in follow fork mode, or run dub in verbose mode to get the dmd command.

The backends knowledge of where things come from is terrible.

For debugging the backend if it's not an obvious segfault or memory corruption etc you better get lucky with a printf or you're out of luck. It's an old and horrible codebase, the trees are simple enough but the algorithms were mostly designed before anything resembling modern compiler design practice.

Feel free to ramble on the d slack about what you've tried so far.

Many thanks for the tips! I managed to debug the code and figured out that the issue was not necessarily caused by my PR, but merely exposed by it. I reduced the source of the bug to roughly the code below:

Tarr foo(Tarr : T[], T)(return scope Tarr x) { return x; }

struct S
{
    import std.container.array : Array;
    Array!int[] x;

    Array!int[] bar()
    {
  	return (foo(this.x[]), this.x[]);
    }
}

My lowering created a CommaExp similar to foo(this.x[]), this.x[]. The second this.x[] caused the backend to think that the symbol this was defined multiple times.

However, I cannot create a bug report with the above code, because it does not compile in this form. foo(this.x[]), this.x[] issues: Error: Using the result of a comma expression is not allowed.

How would you recommend that I report this bug so it's easier to reproduce?