summaryrefslogtreecommitdiffstats
path: root/docs/_images/fib20fig7.png
diff options
context:
space:
mode:
authorSteven <sluong@cisco.com>2018-10-10 14:48:32 -0700
committerDamjan Marion <dmarion@me.com>2018-10-26 19:55:12 +0000
commit557400d778d2fd87e14f3a93f3501f127953c65c (patch)
treee9b4e8050197cd8709062b325a91e6a2e2f0fc6a /docs/_images/fib20fig7.png
parentf208b02624403eeb576b53517a64344dfc76aef2 (diff)
cj: cj dump crash
Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault. 0x00007ffff670da53 in cj_dump_one_record (r=0x7ffff50f0fec) at /home/sluong/vpp3/vpp/src/vlib/unix/cj.c:138 138 (long long unsigned int) r->data[1]); (gdb) p *cjm $1 = {tail = 58645908, records = 0x7fffb64646ec, num_records = 512, enable = 1, vlib_main = 0x7ffff6953240 <vlib_global_main>} (gdb) p /x cjm $2 = 0x7ffff6953880 (gdb) p /x *cjm $3 = {tail = 0x37edd94, records = 0x7fffb64646ec, num_records = 0x200, enable = 0x1, vlib_main = 0x7ffff6953240} (gdb) cjm->tail is a 64 bit counter, not the total number of records. Dumping from 0 to cjm->tail can be a very large number of records which go beyond the limit. I believe we meant to dump from 0 to index. index has been set by this statement index = (cjm->tail + 1) & (cjm->num_records - 1); Change-Id: Ie1a8ba757598de9757accc1488577c15aa49726b Signed-off-by: Steven <sluong@cisco.com>
Diffstat (limited to 'docs/_images/fib20fig7.png')
0 files changed, 0 insertions, 0 deletions