Cryptic DMD error

[Georg Wrede]

Don wrote:
> 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.

It can be fun, too.



The one thing that they never teach you in programming classes is to 
make deliberate errors in code and see what kind of error messages one 
gets. Damn that would have helped me with C++. That kind of stuff should 
have been obligatory excercises the first couple of weeks. The teacher 
could have provided a piece of code that works, and then given a list of 
what errors to introduce (beginning with the trivialest stuff, like 
omitting a semicolon, a parenthesis, etc.).

Once you're used to that, it gets way easier to write your own code. 
Especially with the old C++, where you *never* got a hint about your 
real error. :-(