www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Help with failing assert in dmd.backend.symbol.d

reply Teodor Dutu <teodor.dutu gmail.com> writes:
Hi,

I have recently opened [this 
PR](https://github.com/dlang/dmd/pull/14382) to change 
`_d_arraysetassign` to a template. It has caused [this builkite 
failure in 
vibe-d](https://buildkite.com/dlang/dmd/builds/27898#0182f34a-7f4a-49f9
8b93-01e5ba42998b). 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
Sep 01 2022
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 1 September 2022 at 19:24:24 UTC, Teodor Dutu wrote:

 Hi,

 I have recently opened [this 
 PR](https://github.com/dlang/dmd/pull/14382) to change 
 `_d_arraysetassign` to a template. It has caused [this builkite 
 failure in 
 vibe-d](https://buildkite.com/dlang/dmd/builds/27898#0182f34a-7f4a-49f9
8b93-01e5ba42998b). 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.
Sep 01 2022
prev sibling parent reply max haughton <maxhaton gmail.com> writes:
On Thursday, 1 September 2022 at 19:24:24 UTC, Teodor Dutu wrote:

 Hi,

 I have recently opened [this 
 PR](https://github.com/dlang/dmd/pull/14382) to change 
 `_d_arraysetassign` to a template. It has caused [this builkite 
 failure in 
 vibe-d](https://buildkite.com/dlang/dmd/builds/27898#0182f34a-7f4a-49f9
8b93-01e5ba42998b). 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.
Sep 02 2022
parent Teodor Dutu <teodor.dutu gmail.com> writes:
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:
```d
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](https://github.com/dlang/dmd/blob/7cef3b9f3c43151c5def069a5f281088f561d370/compiler/src/dmd/exp
essionsem.d#L10054) 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?
Sep 12 2022