-
Notifications
You must be signed in to change notification settings - Fork 707
CodingTips
This page aims to capture some lessons learned based on the VPP programming experience. There are no absolutes of course, just some considerations.
use it only for the invariants that must hold true at all times. Do not ever use it for the absent error handling.
And remember that ASSERTs disappear in production images.
You can call abort() in places which you think will cause serious confusion if not announced even in production images.
Use this:
pool_get(per_thread_pool[my_thread_index], p);
rather than this:
spinlock;
pool_get(shared_global_pool, p);
unlock;
p->mumble;
The lock protects the pool, but the p becomes obsolete the moment the lock releases - think of another thread trying to get one more item and the pool being full - it will get reallocated and this will result in a dangling reference into already free memory. Writing to that reference will bring a lot of hours of entertaining troubleshooting.
Remember the distinction between “%v” and “%s”. Format produces vectors, not C-strings; specifically to make it easy to append data. If you need a C-string, either
u8 *s = format (0, “This is a C-string...%c”, 0);
or
u8 *s = format (0, “This is a C-string...”);
vec_add1(s, 0);
Of course if you validate the vector right before use, the below is perfectly sane way to write:
vec_validate (v, i);
v[i] = xxx;
But if you do not validate the vector and assume that the caller must have validated it, Murphy's law will dictate that sometimes they won't (even if the caller is your own code). So, a much safer option is to always use vec_elt() or vec_elt_at_index() - they are a bit more verbose, but you will sleep better.
If you separate the functions displaying the status of your data structures into modules callable with just vlib_main as a parameter, and maybe some primitive arguments - you will be happy when you can call them from gdb during the debugging
Dave B. has added a set of functions in .../src/vnet/unix/gdb_funcs.c, specifically to help people in gdb. If you’ve never tried any of them, try the “show gdb” command:
DBGvpp# show gdb
vl(p) returns vec_len(p)
pe(p) returns pool_elts(p)
pifi(p, i) returns pool_is_free_index(p, i)
debug_hex_bytes (ptr, n_bytes) dumps n_bytes in hex
vlib_dump_frame_ownership() does what it says
vlib_runtime_index_to_node_name (index) prints NN
Examples:
(gdb) p vl(x) # prints vec_len (x)
(gdb) p pifi(pool, i) # prints pool_is_free_index (pool, i)
(gdb) p pe(pool) # prints pool_elts (pool)
separate heap might be a good idea if your logic gets complicated. This way you get a good way to track your own memory usage and ensure that the faults are contained. If you create your own heap, remember to set a thread safe flag - the global heap is thread safe, and also to switch the heap back to what it was before calling the library functions! You do get a headache of that, but the bugs that this has the potential to create (crash due to an assertion failing about foo_header being a heap object) are not hard to find and fix.
The mheap allocator can trace allocations - with backtrace info - ordinarily I warm up data structures, then turn on leak tracing. After a few , a bit of “show memory” action will give leaked memory sizes, counts, and backtraces. That’s usually 100% effective in tracking down memory leaks.
If the heap is corrupted, sprinkle clib_mem_validate() calls in likely places. Eventually, you’ll find the offending bit of code.
This page was created and is maintained by ayourtch, capturing some of his ideas as well as suggestions from Dave Barach.