Bug 4481 – ICE(glue.c,!vthis->csym) or compiles, depending on the import statements order

In some specific circumstances DMD 2.047 segfaults or not segfaults depending on the order of imported modules. The message produced in case of the : Assertion failure: '!vthis->csym' on line 694 in file 'glue.c' ATM the reliable set of conditions on which I can reproduce this are: - at least 2 modules (all source dumped in one file avoids this issue) - both import std.algorithm (though I still belive it has little to do with it) - one module defines class which then uses std.reduce - another one imports it *and* std.algorithm in a specific order. Well, it looks like it's very subtle - one slight change and it no longer manifests. Took almost one day to cut it down to a resonable size. //---------------- The test case ---------------- import std.algorithm;//move this import statement after the next one or just comment, and everything compiles import g; void main(){} ///g.d module g; import std.algorithm; class Font{// rewriting all of the functions below as free functions and it again compiles public: int charHeight(dchar c){ return 0; } int textHeight(in string text){ auto maxHeight = (int h,dchar ch){ return max(h,charHeight(ch)); }; return reduce!(maxHeight)(text); } }

Hm, it has something to with how you pass the files to DMD, for the test case above: dmd g.d main.d - compiles, all Ok dmd main.d g.d - Assertion failure: '!vthis->csym' on line 694 in file 'glue.c'

This looks similar to bug 2692. It's not a duplicate, but I suspect the root cause is the same.

(In reply to comment #2) > This looks similar to bug 2692. It's not a duplicate, but I suspect the root > cause is the same. I'm 100% sure you meant bug 2962 that is "ICE(glue.c) or bad codegen passing variable as template value parameter" and not bug 2692 which is "alignment of double on x86 linux is incorrect" and resolved

(In reply to comment #3) > (In reply to comment #2) > > This looks similar to bug 2692. It's not a duplicate, but I suspect the root > > cause is the same. > > I'm 100% sure you meant bug 2962 that is > "ICE(glue.c) or bad codegen passing variable as template value parameter" > and not bug 2692 which is > "alignment of double on x86 linux is incorrect" and resolved Correct. In this bug, it's the 'this' parameter which causes the problem, in bug 2962 it's any other function parameter.

*** Issue 8071 has been marked as a duplicate of this issue. ***

Hit this again today (DMD git, also in 2.059). In case this bug got buried or thought to be fixed, I'll note that bugs 2692 and 2962 are both marked as fixed, so this bug isn't a duplicate of those.

I got this with dmd 2.060, I got it reduced down to this: -- main.d module main; import std.algorithm; import collection; -- -- collection.d module collection; import std.algorithm; struct Collection { int[] collection; void test(Collection[] coll) { auto element = collection[0]; auto result = coll.map!(v => v.collection[0] * element); } } -- If the std.algorithm import is commented out in main.d it works fine, also if element is replaced with collection[0] in the map lambda in collection.d

2.062head has a regression caused by this problem, probably. Reduced test case is here. Command: dmd.exe bug2062a.d bug2062b.d bug2062a.d ---------------------------- void call(alias pred, R)(R haystack) { foreach (e; haystack) { pred(e); break; } } bug2062b.d ---------------------------- import bug2062a; class Foo { void member() { int[] r; int local; call!(p=>local)(r); // ( (int p)=>local ) works. } }

(In reply to comment #8) Sorry, 2.062 has just come, and it doesn't reproduce above. Then, it was not a regression in 2.062head, but in 2.063head(or master).

I cannot reproduce neither of three samples (original, comment 7, comment 8). Tested with today released 2.062 on windows.

I see. I did wrong process. We should get source from 'staging' branch to check if bugs are fixed, not from 'master'. So, it is not a regression. Sorry to have bothered you. And this issue seems to be fixed in 2.062, I agree.

2.063 has another variant of this still. If i use struct with opCall (because my sort needs a third variable) then it still crashes depending what order it is imported. Crashes with glue.c:786: virtual void FuncDeclaration::toObjFile(int): Assertion `!vthis->csym' failed. //crash.d // import anything a bit complex import std.stdio; // crash import crashb; import std.stdio; //no crash void main() { auto a = new A; a.sort(); } ///crashb.d module crashb; import std.algorithm; struct Sorter { bool opCall(int a, int b) { return a < b; } } class A { void sort() { uint[] s; Sorter sorter; std.algorithm.sort!sorter(s); } }

Here is another variant of this. [DMD2.063.2] dmd crasha.d crashb.d ===> Assertion failure: '!vthis->csym' on line 783 in file 'glue.c' // crasha.d --------------------- import std.algorithm; // crashb.d --------------------- import std.algorithm; class SomeClass { void foo() { //enum myFilter = function(int s)=>true; // OK auto myFilter = function(int s)=>true; // NG int[] r; r.filter!myFilter(); } }

Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/165f15bf71537f863943599f4782b6c0b54c37eb fix Issue 4481 - ICE(glue.c,!vthis->csym) or compiles, depending on the import statements order https://github.com/D-Programming-Language/dmd/commit/2389c3552b44467a77861a61be445eb09a4a376f Merge pull request #2463 from 9rnsr/fix4481 Issue 4481 - ICE(glue.c,!vthis->csym) or compiles, depending on the import statements order