Created attachment 1183
reduced test case
DMD crashes when compile the attaced source files with -cov switch.
They are reduced, but have many many blank lines to keep line number.
Environment:
Windows7 64-bit ( Non -m64 )
Comment #1 by kekeniro2 — 2013-02-06T18:33:13Z
DMD crashes but its process is alive.
DMD 2.058 or older, seems to go silently into loop.
Comment #2 by andrej.mitrovich — 2013-02-06T18:40:50Z
It crashes in Module::genobjfile, in this call:
free(covb);
covb is allocated via:
covb = (unsigned *)calloc((numlines + 32) / 32, sizeof(*covb));
I would sure like to understand the meaning of this magical expression. Why is it dividing by 32? Another case of premature optimization?
If you replace that with:
covb = (unsigned *)calloc(numlines, sizeof(*covb));
Then it works fine.
Comment #3 by andrej.mitrovich — 2013-02-08T11:06:51Z
Created attachment 1184
More reduced test case
If move the code line `int dummy = 0;` in cb.i from line 161 to 160, segfault disappeared. The line number depends on minimum allocation size of calloc(). As far as I see, currently it allocates at least 20 bytes (20 * 8 == 160 bit).
Comment #5 by andrej.mitrovich — 2013-02-09T06:10:46Z
The pull was invalid, I'll let others handle this one.
Comment #6 by kekeniro2 — 2013-05-21T20:50:42Z
Probably this is a duplicate of Issue 9353.
Comment #7 by bugzilla — 2013-05-21T22:53:23Z
(In reply to comment #2)
> covb is allocated via:
>
> covb = (unsigned *)calloc((numlines + 32) / 32, sizeof(*covb));
>
> I would sure like to understand the meaning of this magical expression. Why is
> it dividing by 32? Another case of premature optimization?
covb is a bit vector, it must have numlines bits in it. Since unsigned's are 32 bits wide, it rounds it up to the number of 32 bit unsigned's to allocate.
Comment #8 by bugzilla — 2013-10-01T23:21:13Z
Can't duplicate any problem with 2.064 head, although it does fail with 2.063.
Comment #9 by andrej.mitrovich — 2013-10-02T05:54:36Z
(In reply to comment #8)
> Can't duplicate any problem with 2.064 head, although it does fail with 2.063.
I can reproduce it with git-head. Have you made sure to compile with:
dmd.exe -cov -c cb.d -J.
Comment #10 by kekeniro2 — 2013-10-02T07:29:35Z
I made a DMD.exe of 2.063.2 by the _tuned_ DMC. (Memory allocation improvement ver.)
It does _not_ reproduce the bug ... why?
Comment #11 by andrej.mitrovich — 2013-10-02T08:03:03Z
(In reply to comment #10)
> I made a DMD.exe of 2.063.2 by the _tuned_ DMC. (Memory allocation improvement
> ver.)
> It does _not_ reproduce the bug ... why?
Which tuned DMC?
Comment #12 by kekeniro2 — 2013-10-02T08:19:52Z
(In reply to comment #11)
> (In reply to comment #10)
> > I made a DMD.exe of 2.063.2 by the _tuned_ DMC. (Memory allocation improvement
> > ver.)
> > It does _not_ reproduce the bug ... why?
>
> Which tuned DMC?
I mean DMC 8.57 and new snn.lib, which came in August.
DMC 8.57
http://forum.dlang.org/thread/[email protected]
snn.lib
http://forum.dlang.org/thread/[email protected]
Comment #13 by andrej.mitrovich — 2013-10-02T08:27:19Z
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > I made a DMD.exe of 2.063.2 by the _tuned_ DMC. (Memory allocation improvement
> > > ver.)
> > > It does _not_ reproduce the bug ... why?
> >
> > Which tuned DMC?
>
> I mean DMC 8.57 and new snn.lib, which came in August.
>
> DMC 8.57
> http://forum.dlang.org/thread/[email protected]
> snn.lib
> http://forum.dlang.org/thread/[email protected]
I still get a crash with these when using with both 2.063.2 and 2.064.
Comment #14 by bugzilla — 2013-11-16T11:32:34Z
Cannot reproduce with 2.064 or 2.065 head.
Comment #15 by andrej.mitrovich — 2013-11-16T11:35:50Z
(In reply to comment #14)
> Cannot reproduce with 2.064 or 2.065 head.
Looks like it's gone with the release version on 2.064.
Reopen if you run into it again.
Comment #16 by bugzilla — 2013-11-16T12:17:36Z
Running under valgrind uncovered the error. Will post fix shortly.