In the vxdclid core dump, can see the following stack trace :
t_splay (a6b970, 30, aa8720, fecd7afc, ff1303d8, 0) + f4
realfree (a6b938, 33, d8a50, ff34d6cc, 0, b) + 8c
_free_unlocked (ff1392b0, 0, d827c, ff139330, ff1303d8, 1495848) + b0
free (1495848, 0, d82bc, ff0c2f40, ff1303d8, ff133a20) + 24
dcliFree (1495848, ffffff, ff000000, 0, f, fffc00) + c
rb_destroy (a60240, 0, 0, ff139330, ff1303d8, ff133a20) + 1e4
vx_map_destroy (a60240, 0, ff135900, 0, fef92200, ff133a20) + c
stats_free (a5e070, 0, ff135900, 0, fef92200, fffc00) + d8
map_stats_free (a5e070, 0, 0, ff139330, 1, ff133a20) + c
rb_destroy (907ad8, 0, ff135900, 0, fef92200, 4e0877b0) + 154
vx_map_destroy (907ad8, 174e088, 92ba18, 0, 1, ff137580) + c
logstats_work (fedd1fd8, 0, 0, 0, fef92200, 0) + bc
logstats_thread (0, fe6fc000, 0, 0, fecd9190, 1) + 34
_lwp_start (0, 0, 0, 0, 0, 0)
The issue has been reported as a BUG and has the fix available in VxVM patch 5.1SP1RP1P2HF4.
As a workaround, comment out the following three lines in file /etc/vx/dcli/sfm/conf/dcli_conf.ini:
#VolumeLog = /var/opt/VRTSsfmh/stats/6hour.vrts_vxvm_volume
#DiskLog = /var/opt/VRTSsfmh/stats/6hour.vrts_vxvm_disk
#DmpCtlrLog = /var/opt/VRTSsfmh/stats/6hour.vrts_dmp_ctlr .
Applies To
After applying SF-5.1SP1RP1P2HF1 patch set to the host, the vxdclid process doesn't function properly. However, at previous patch levels, it works fine.