digitalmars.D - Help with failing assert in dmd.backend.symbol.d
- Teodor Dutu (17/17) Sep 01 2022 Hi,
- Nicholas Wilson (6/23) Sep 01 2022 You should be able to run dub in verbose mode to spit out the
- max haughton (10/27) Sep 02 2022 Try running gdb in follow fork mode, or run dub in verbose mode
- Teodor Dutu (25/35) Sep 12 2022 Many thanks for the tips! I managed to debug the code and figured
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
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, TeodorYou 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
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, TeodorTry 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
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