I looked at the dump you sent me.  the instructions being executed
just before the fatal trap were:


0xc0365a19 <mountd_set_exports_list+137>:       mov    0xffffffa8(%ebp),%edi
0xc0365a1c <mountd_set_exports_list+140>:       mov    0x30(%edi),%ebx
0xc0365a1f <mountd_set_exports_list+143>:       mov    0x8(%ebx),%edx
0xc0365a22 <mountd_set_exports_list+146>:       mov    %ebx,0xffffff70(%ebp)
0xc0365a28 <mountd_set_exports_list+152>:       mov    0x28(%edx),%eax
0xc0365a2b <mountd_set_exports_list+155>:       test   %eax,%eax
0xc0365a2d <mountd_set_exports_list+157>:
    je     0xc0365a36 <mountd_set_exports_list+166>
0xc0365a2f <mountd_set_exports_list+159>:       mov    0x24(%edx),%eax
0xc0365a32 <mountd_set_exports_list+162>:       test   %eax,%eax
0xc0365a34 <mountd_set_exports_list+164>:
    jne    0xc0365a47 <mountd_set_exports_list+183>
...
0xc0365a47 <mountd_set_exports_list+183>:       mov    %edi,(%esp,1)
0xc0365a4a <mountd_set_exports_list+186>:       lea    0xffffff78(%ebp),%ecx
0xc0365a50 <mountd_set_exports_list+192>:       mov    %ecx,0x4(%esp,1)
0xc0365a54 <mountd_set_exports_list+196>:       call   *0x28(%edx)


the registers at the time of the trap were:

(gdb) p *frame
$2 = {tf_gs = 0xcb5b0010, tf_fs = 0x30, tf_es = 0xc1540010, 
  tf_ds = 0xcb5b0010, tf_edi = 0xcb9b5f20, tf_esi = 0xcb5bfe14, 
  tf_ebp = 0xcb5bfd1c, tf_ebx = 0xc15bc000, tf_edx = 0xc154d740, 
  tf_ecx = 0xc093ed60, tf_eax = 0xcb8579e0, tf_trapno = 0x6, tf_err = 0x0, 
  tf_eip = 0x0, tf_cs = 0x8, tf_eflags = 0x10286, tf_esp = 0xc04a8308, 
  tf_ss = 0xcb8579e0, tf_vm86_es = 0xcb5bfd44, tf_vm86_ds = 0xcb5bfdcc, 
  tf_vm86_fs = 0xc0365a57, tf_vm86_gs = 0xcb9b5f20}


whereas the contents of memory indicate that %edx should have had a
different value:

(gdb) x/x 0xcb5bfdcc+0xffffffa8
0xcb5bfd74:     0xcb9b5f20
(gdb) x/x 0xcb9b5f20+0x30
0xcb9b5f50:     0xc15bc000
(gdb) x/x 0xc15bc000+8
0xc15bc008:     0xc093ede0
(gdb) x/x 0xc093ede0+0x28
0xc093ee08 <nullfs_vfsops+40>:  0xc04a82e0
(gdb) x/i 0xc04a82e0
0xc04a82e0 <layerfs_vptofh>:    push   %ebp


since %edx has the wrong value, when we call through it we end up in limbo:

(gdb) x/x 0xc154d740+0x28
0xc154d768:     0x00000002

I don't see how this could happen.

-Chuck