#277 assertion failed: vector.c:816

[Ed Spittles]

Hi Trevor
something odd is happening which seems to corrupt the 'base' pointer as seen by the vector_merge() function.

I'll send you a couple of cdd files which exhibit this problem when merged.

gdb shows the 'base' pointer is invalid:
(gdb) frame 4

4 0x080ca22a in vector_merge (base=0x627e, other=0xbc579a0) at vector.c:816

816 assert( base->width == other->width );

whereas in the parent function all looks reasonable:
(gdb) up

5 0x0807eae3 in expression_merge (base=0x9b0c660, other=0xbc26ed8) at expr.c:1816

1816 vector_merge( base->value, other->value );
(gdb) print base->value
$16 = (vector ) 0x9b1f9d8
(gdb) print other->value
$17 = (vector ) 0xbc579a0

I've built with gcc 4.4.0 and 4.0.1 using both O1 and O3 and the problem is the same. I see nothing untoward in valgrind or with mudflap checks.

Please let me know if you need more information

Thanks
Ed

[Trevor Williams]

Ed,

Could you tell me what the signal a1051 is defined as? In y1, Covered is treating it as a 1-bit wide signal but in y2, it is treated as an 8-bit signal. Is it sized by a parameter? I think that the problem is in the score command but I need to understand why each design file is is created differently.

Thanks,
Trevor

[Nobody/Anonymous]

Hi Trevor
a1051 is a reg [7:0], no parameters involved.

y1 and y2 are truncations, the full-size obfuscated cdd files being x1 and x2. If I grep those files for a1051 I get these lines:
x1: 2 176 0 0 0 1 1000 0 0 1 1 a1050.a1051
x1: 2 1576 634 60025 0 1 1400 0 0 8 1 a1051
x1: 2 1765 641 100034 0 24 1400 1763 1764 4 18 0 f 0 0 0 0 a1051
x1: 2 1770 640 100034 0 24 1400 1768 1769 4 18 0 f 0 0 0 0 a1051
x1: 2 1775 639 100034 0 24 1400 1773 1774 4 18 0 f 0 0 0 0 a1051
x1: 2 1780 638 100034 0 24 1400 1778 1779 4 18 0 f 0 0 0 0 a1051
x1: 2 1787 637 100034 0 24 1400 1785 1786 3 18 0 7 0 0 0 0 a1051
x1: 2 1797 632 60025 0 1 1400 0 0 8 1 a1051
x1: 1 a1051 245 474 1070030 1 0 7 0 8 17 0 ff 0 0 0 0
x1: 2 2149 644 a0029 0 1 1400 0 0 8 1 a1051
x1: 2 2182 698 260045 0 1 1000 0 0 8 1 a1051
x2: 2 176 0 0 2cc51 1 100c 0 0 8 1 a1050.a1051
x2: 2 1576 634 60025 0 1 1410 0 0 8 1 a1051
x2: 2 1765 641 100034 0 24 1410 1763 1764 4 18 0 f 0 0 0 0 a1051
x2: 2 1770 640 100034 0 24 1410 1768 1769 4 18 0 f 0 0 0 0 a1051
x2: 2 1775 639 100034 0 24 1410 1773 1774 4 18 0 f 0 0 0 0 a1051
x2: 2 1780 638 100034 0 24 1410 1778 1779 4 18 0 f 0 0 0 0 a1051
x2: 2 1787 637 100034 0 24 1410 1785 1786 3 18 0 7 0 0 0 0 a1051
x2: 2 1797 632 60025 0 1 1410 0 0 8 1 a1051
x2: 1 a1051 245 474 1070030 1 0 7 0 8 17 0 ff 0 a2 a2 0
x2: 2 2149 644 a0029 0 1 1410 0 0 8 1 a1051
x2: 2 2182 698 260045 1be7e 1 100c 0 0 8 1 a1051

Hope this helps
Ed

[Ed Spittles]

Hi Trevor
I should add, one of these is unscored: it is from score with a vcd. My script starts with an unscored cdd and then merges in each of the scored files for a campaign.

Ed

[Trevor Williams]

Bug fix patch

[Trevor Williams]

I have attached a bug fix patch for this issue which can be applied to the stable branch. It will be generally available in the next stable and development release of Covered.

The issue had to do with merging unscored CDD files with scored CDD files. The former do not add any information to the overall coverage count; therefore, the fix is to discard any unscored CDD files from the merge process. If all of the CDD files specified on the merge command-line are unscored, Covered will emit an error; otherwise, no error will occur.

[SourceForge Robot]

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).