#288 Assertion sig->udim_num == 0 failed

[Ed Spittles]

Hi Trevor

Having tweaked the sources to workaround the problem with loops initialising memories, I'm seeing an assertion at the time of scoring the vcd file.

I have been able to cut down the vcd file to mention only a single signal, and I've got obfuscated versions of the vcd and the cdd, but I can't readily create a subset of the cdd file.

Is there anything useful I can do in the debugger to find out what went wrong?

Here's the visible error:
Scoring VCD dumpfile testcase.vcd...
covered: vsignal.c:528: vsignal_vcd_assign: Assertion `sig->udim_num == 0' failed.
Aborted (core dumped)

The backtrace is:

0 0xffffe405 in __kernel_vsyscall ()

1 0xf7d9fdf0 in raise () from /lib/tls/i686/cmov/libc.so.6

2 0xf7da1641 in abort () from /lib/tls/i686/cmov/libc.so.6

3 0xf7d9943b in __assert_fail () from /lib/tls/i686/cmov/libc.so.6

4 0x080f82ee in vsignal_vcd_assign (sig=0x929d450, value=0x920c860 '0' <repeats 30="" times="">, "10", msb=0, lsb=30459, time=0x8142158)</repeats>

at vsignal.c:528

5 0x080e2093 in symtable_assign (time=0x8142158) at symtable.c:511

6 0x08076553 in db_do_timestep (time=0, final=FALSE) at db.c:3459

7 0x080e965f in vcd_parse (vcd_file=0x91f40f8 "testcase.vcd") at vcd.new.c:529

8 0x080c44c3 in parse_and_score_dumpfile (db=0x91f4158 "testcase.trunc.cdd", dump_file=0x91f40f8 "testcase.vcd", dump_mode=1) at parse.c:290

9 0x080d8792 in command_score (argc=9, last_arg=1, argv=0xffd1be64) at score.c:1292

10 0x080bbf06 in main (argc=9, argv=0xffd1be64) at main.c:189

Looking at level 4, we're in vsignal_vcd_assign

The variable 'sig' seems very dubious - the name is not valid:
(gdb) info args
sig = (vsignal ) 0x929d450
value = 0x920c860 '0' <repeats 30="" times="">, "10"
msb = 0
lsb = 30459
time = (const sim_time </repeats>) 0x8142158
(gdb) print *sig
$1 = {id = 153736400, name = 0x23

, line = 4096, suppl = {all = 3397, part = {col = 3397, type = 0, big_endian = 0,
excluded = 0, not_handled = 0, assigned = 0, mba = 0, implicit_size = 0}}, value = 0xffffffff, pdim_num = 1150, udim_num = 1906,
dim = 0x772, exp_head = 0x0, exp_tail = 0x260045}

going up one level, we're in symtable-assign
(gdb) up

5 0x080e2093 in symtable_assign (time=0x8142158) at symtable.c:511

511 vsignal_vcd_assign( sig->sig, curr->value, sig->msb, sig->lsb, time );

and the pointer sig looks a bit dubious to me:
(gdb) print *sig
$3 = {sig = 0x929d450, msb = 1834942546, lsb = 153164928, next = 0x19}

That next pointer looks wrong, as do the msb and lsb.

Starting with the curr pointer, we see
(gdb) print curr
$5 = {entry = {sig = 0x92163f8, exp = 0x92163f8, table = 0x92163f8}, entry_type = 0 '\0', value = 0x920c860 '0' <repeats 30="" times="">, "10",
size = 33, table = {0x0 <repeats 94="" times="">}}
and the first and second entries look good, but the third one is the dubious one:
(gdb) print </repeats></repeats>curr->entry.sig
$6 = {sig = 0x93fbb10, msb = 31, lsb = 0, next = 0x9211c90}
(gdb) print curr->entry.sig->next
$8 = {sig = 0x93ef518, msb = 31, lsb = 0, next = 0x920cda0}
(gdb) print curr->entry.sig->next->next
$9 = {sig = 0x929d450, msb = 1834942546, lsb = 153164928, next = 0x19}

Please let me know how I might help - or open a chat if you like.

Cheers
Ed

[Ed Spittles]

Hi Trevor
is there anything I can do to help you with this?
Cheers
Ed

[Trevor Williams]

This problem seems to be due a bug in Verilator's VCD header output generator. It is aliasing signals that should not be aliased. I will submit a bug to Verilator on this issue.

I have attached a patch that will cause Covered to emit a different assertion error that checks for this specific error case.

[Trevor Williams]

Adds assertions to catch the Verilator bug

[Ed Spittles]

Hi Trevor
I've finally been able to re-run with your patch, and indeed the failing case now hits a different assertion error:

3 0x555da43b in __assert_fail () from /lib/tls/i686/cmov/libc.so.6

4 0x080e2671 in symtable_add_signal (sym=0xffc4263a "", sig=0x978f458, msb=31, lsb=0) at symtable.c:180

5 0x08076bbf in db_assign_symbol (name=0xffc42538 "i", symbol=0xffc42638 "Iy", msb=31, lsb=0) at db.c:3319

6 0x080e8f9a in vcd_parse_def_var (vcd=<value optimized="" out="">) at vcd.new.c:329</value>

7 0x080e95ab in vcd_parse_def (vcd=<value optimized="" out="">) at vcd.new.c:378</value>

8 0x080e97f3 in vcd_parse (vcd_file=0x95a6118 "fake.vcd") at vcd.new.c:564

where line 180 of symtable.c is
180 assert( (symtab->entry_type == 0) || (symtab->entry_type == 1) );

Hopefully this is as you expect. Just to verify that I'm seeing the same problem that you've determined to be an erroneous vcd file, I've explored some of the state of covered at the time of the assert:

(Note that symtable_add_sym_sig is inlined into symtable_add_signal)

(gdb) p curr
$1 = (symtable ) 0x9814aa8
(gdb) p curr
$2 = {entry = {sig = 0x9685378, exp = 0x9685378, table = 0x9685378}, entry_type = 2 '\002', value = 0x9684d50 "", size = 33,
table = {0x0 <repeats 94="" times="">}}
(gdb) p curr->entry.sig
$3 = {sig = 0x9643ea0, msb = 157832530, lsb = 0, next = 0x19}
(gdb) p curr->entry.sig->sig
$4 = {id = 157564680, name = 0x23 </repeats>

, line = 4096, suppl = {all = 3020, part = {col = 3020, type = 0,
big_endian = 0, excluded = 0, not_handled = 0, assigned = 0, mba = 0, implicit_size = 0}}, value = 0xffffffff,
pdim_num = 1029, udim_num = 1765, dim = 0x6e5, exp_head = 0x0, exp_tail = 0x25003f}
(gdb) print sym
$6 = 0xffc4263a ""
(gdb) print *sym
$7 = 0 '\0'

(I don't like the look of that - why is *sym an empty string?)

Going up to the parent code and looking at the state there:
(gdb) up

5 0x08076bbf in db_assign_symbol (name=0xffc42538 "i", symbol=0xffc42638 "Iy", msb=31, lsb=0) at db.c:3319

3319 symtable_add_signal( symbol, sig, msb, lsb );
(gdb) l
3314
3315 / Only add the symbol if we are not going to generate this value ourselves /
3316 if( SIGNAL_ASSIGN_FROM_DUMPFILE( sig ) ) {
3317
3318 / Add this signal /
3319 symtable_add_signal( symbol, sig, msb, lsb );
3320
3321 }
3322
3323 }
(gdb) p symbol
$8 = 0xffc42638 "Iy"
(gdb) p sig
$9 = (vsignal ) 0x978f458
(gdb) p sig
$10 = {id = 891, name = 0x978f4c8 "i", line = 55, suppl = {all = 17235979, part = {col = 11, type = 7, big_endian = 0,
excluded = 0, not_handled = 0, assigned = 1, mba = 0, implicit_size = 0}}, value = 0x978f438, pdim_num = 1, udim_num = 0,
dim = 0x978f3e8, exp_head = 0x97af6e8, exp_tail = 0x97af938}
(gdb) p msb
$11 = 31
(gdb) p lsb
$12 = 0

This all looks OK to me. Symbol 'Iy' is indeed found in the vcd file, although it does look like it might be re-used, which would indicate this is the same problem you saw:

Here's an extract from the vcd:
$scope module TOP $end
$scope module v $end
$scope module aos_jd_0_u $end
$var wire 32 Iy covered$I1765_1765_4001e$aos_jd_d_valid_d_r$aos_jd_parse_fsm_combinatorial_l [31:0] $end
$var wire 32 Iy covered$R1765_1765_25003f$aos_jd_d_valid_q_r$aos_jd_parse_fsm_combinatorial_l [31:0] $end
$scope module aos_jd_buff_in_u $end
$var wire 32 Iy i [31:0] $end
$upscope $end
$scope module aos_jd_buff_out_u $end
$var wire 32 Iy i [31:0] $end
$upscope $end