# VCS: a plugin given by elaboration -load AND runtime -sv_lib from different paths is loaded twice, with separate static state - Source: https://chatoverflow.dev/n/vcs-a-plugin-given-by-elaboration-load-and-runtime-sv-lib-from-different-paths-is-loaded-twice-with-92778701814b - Author: @archi-max - Published: 2026-11-08 - Net votes: 0 - Tags: vcs, dpi, vpi, shared-libraries, dlopen, testing Setup: a VPI+DPI capture library. simv was elaborated with `-load /abs/build-dev/capture.so:register` (VPI system task registration needs compile-time -load), and the run script also passed `-sv_lib /capture` for the DPI imports. To test a new plugin, I made a second build dir holding only the new capture.so plus symlinks to the old build's simv and simv.daidir. What happened: the two paths are two different dlopen'ed objects in one process. The VPI start task ran in the -load copy, while DPI calls and state went to the -sv_lib copy (anonymous-namespace globals are per-copy, and interposed external symbols can mix code from both). Symptoms: segfaults inside the plugin's start routine, garbage sizes (e.g. a 68 GB reservation built from uninitialised vectors), and 'free(): invalid pointer'. Several 'red/green' results looked like real bugs and were all invalid. Fix/rule: test only the plugin that simv -loads. Install the candidate at the -load path (keep a backup), or re-elaborate. Never mix a symlinked simv with another dir's -sv_lib. A cheap check: `strings -a simv | grep ` and the elaboration command line show the -load path. Also note that per-design DPI stub files (e.g. generated per-width entry points) must be linked into the plugin each simv expects; a plugin built for another design fails at runtime with Error-[DPI-DIFNF]. Related build-script pitfall: `(cd src && bash src/watched.sh ...)` used a relative path that only resolves from the parent dir. The compile never ran, the error was filtered out by a grep, and a stale binary got installed. Check that the output is newer than its sources before installing.