Null pointer dereference in fellow_busy_body_seg_next due to fbo->body_seglist == NULL

From #32 (comment 1625347355) reported by @jlcox70

Signal 11 (Segmentation fault) received at 0x8 si_code 1
...
   0x7f8624bd6720: vext_cache/libvmod_slash.so,xogidlnt.so(fellow_busy_obj_getspace+0x300) [0x7f8624bd6720]

Annotated objdump snippet with fellow_busy_body_seg_next() inlined into fellow_busy_obj_getspace():

   // PANIC <-
   4d6f0:	49 8b 46 30          	mov    0x30(%r14),%rax // AN(fcs->alloc.size);
   4d6f4:	48 85 c0             	test   %rax,%rax
   4d6f7:	0f 84 a7 07 00 00    	je     4dea4 <fellow_busy_obj_getspace+0xa84>
   4d6fd:	49 8b 56 38          	mov    0x38(%r14),%rdx  // fcs->len
   4d701:	48 39 d0             	cmp    %rdx,%rax
   						// jmp if (fcs->len < fcs->alloc.size)
   4d704:	0f 87 16 04 00 00    	ja     4db20 <```
+0x700>
						// assert(fcs->len == fcs->alloc.size);
   4d70a:	0f 85 f8 0a 00 00    	jne    4e208 <fellow_busy_obj_getspace+0xde8>
   // fellow_busy_body_seg_next
   4d710:	81 3b 32 a1 04 85    	cmpl   $0x8504a132,(%rbx) // FELLOW_BUSY_MAGIC
   4d716:	0f 85 04 08 00 00    	jne    4df20 <fellow_busy_obj_getspace+0xb00>
   4d71c:	48 8b 6b 50          	mov    0x50(%rbx),%rbp // fcsl = fbo->body_seglist;
   4d720:	48 8b 45 08          	mov    0x8(%rbp),%rax		// <===
   4d724:	48 85 c0             	test   %rax,%rax

If I analyzed the code correctly, the panic was caused by fbo->body_seglist == NULL here: The segmentation violation was at address 0x8, which is the offset of the fdsl member:

(gdb) p offsetof(struct fellow_cache_seglist, fdsl)
$7 = (struct fellow_disk_seglist **) 0x8

The OP reported that this issue had not been triggered since they stopped used a shared memory cache, so the likely cause is incomplete error handling for a seglist allocation.