Cryptic DMD error

[Don]

Georg Wrede wrote:
> Don wrote:
>> Lars T. Kyllingstad wrote:
>>> Don wrote:
>>>> Lars T. Kyllingstad wrote:
>>>>> Can someone with knowledge of the DMD source code please explain 
>>>>> this error message for me?
>>>>>
>>>>> dmd: glue.c:652: virtual void FuncDeclaration::toObjFile(int): 
>>>>> Assertion `!v->csym' failed.
>>>>>
>>>>> I had a look at the DMD source to try and make some sense of it 
>>>>> myself, but didn't succeed. I am using the latest DMD, 2.029.
>>>>>
>>>>> I am in the middle of porting a library from D1 to D2, and as there 
>>>>> is no mention of a file name, let alone a line number, I find it 
>>>>> hard to narrow down the cause of the error.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Lars
>>>> Compile with -v, and you'll find the file DMD was working on when it 
>>>> crashed. Please enter a test case into Bugzilla.
>>>
>>>
>>> Thank you! Thanks to this little piece of advice, I've managed to 
>>> narrow  it down enormously, and also to work around it. I'm having 
>>> problems reproducing it as a simple test case, though.
>>>
>>> Using the -v switch, the last thing DMD says before bailing out is 
>>> "function  qagiIntegrateUpper". So here's a snippet from the 
>>> troublesome code:
>>>
>>> ---
>>> Result!(Real) qagiIntegrateUpper(Real, Func)
>>>   (Func f, Real a, Real epsAbs, Real epsRel, Workspace!(Real) workspace)
>>> {
>>>     mixin AssertRealType!("qagiIntegrate", Real);
>>>     mixin AssertSignature!("qagiIntegrate", Func, Real, Real);
>>>
>>>     // Map onto the interval (0, 1).
>>>     auto trans = transform!(Func, "f(a + (1-t)/t)/(t*t)", a)(f);
>>>
>>>     return qagsIntegrate(trans, cast(Real)0.0, cast(Real)1.0,
>>>         epsAbs, epsRel, workspace, Rule.GK15);
>>> }
>>> ---
>>>
>>> The line that starts with "auto trans ..." is the one that causes 
>>> problems. The function transform!(...)(f) does what you think it 
>>> does; it takes the function f and transforms it according to the 
>>> string template parameter. The result is a struct with an opCall 
>>> method and a field containing a copy of the template parameter a 
>>> (which is passed to the template by alias).
>>>
>>> I've been able to work around the error by replacing this line with 
>>> the following:
>>>
>>> ---
>>> Real b = a;
>>> auto trans = transform!(Func, "f(b + (1-t)/t)/(t*t)", b)(f);
>>> ---
>>>
>>> Thus, what is passed on to transform() is a locally declared 
>>> variable, and not an argument to the function qagiIntegrateUpper(). 
>>> Why this should matter, I have no idea.
>>
>> There're a bit less well tested <g>. Probably you've created a wierd 
>> combination of features noone has ever done before.
>>
>>>
>>> But, as already mentioned, I have so far not been able to create a 
>>> simple test case for reproducing the bug, and I'm pretty sure nobody 
>>> wants the entire code for transform() in Bugzilla...
>>>
>>> I'll continue working on it, though.
>>>
>>> -Lars
>> There's quite an art to it.
>>
>> If the code isn't commercial, so that you can post a test case (even 
>> if it's huge), that'd still be OK. Especially if you can manage to get 
>> it all into a single file. Someone posted a 3Mb source file in there 
>> once.
>>
>> Try transform!(Func, "f(b)", b)(f);
> 
> I've sometimes wondered about shortening code for those bug reports. 
> It's typically a task that seems daunting, especially as one often 
> encounters that in big and complicated apps in D. There must be some 
> very good (possibly language independent) advice on the net for quickly 
> and efficiently doing it, just haven't found any.
> 
> Stuff like (what I call) binary drilling (removing "half" of the code, 
> and if the bug disappears, then taking half of the removed part back, 
> etc. Or, say, putting pragma messages in various places to see which one 
> was the last seen.
> 
> Just like there is a lot of advice (and books) on debuggin in general.

Cutting down compiler bugs is a really valuable exercise. I learnt an 
enormous amount from it, which I've used professionally.
I'm not primarily employed as a programmer, at present I'm an engineer 
on a production line. And the idea of finding the simplest possible 
scenario which reproduces a problem is tremendously helpful. I've never 
seen a better example of it than tracking down DMD bugs.