vvp hangs forever on msys2 but does not on linux

[Kreijstal]

I am doing cosimulation between verilator and icarus on both linux and windows (You need 5.026 of verilator), gcc

Essentially vvp finishes the testbench and blocks forever, for some reason.

This is the minimal reproduction. https://gist.github.com/Kreijstal/ac8dff5de2b771fc6ccde9db433d73d1

git clone https://gist.github.com/ac8dff5de2b771fc6ccde9db433d73d1.git bug
cd bug
make

On linux you get

IVERILOG_DIR = /usr/include/iverilog
VPI_INCLUDE_DIR = /usr/include/iverilog
mkdir -p obj_dir
gcc -Wall -g -I/usr/share/verilator/include -I/usr/include/iverilog -Iobj_dir -fPIC -DVL_TIME_CONTEXT -I/usr/include/iverilog -fPIC -c and_gate_vpi.c -o obj_dir/and_gate_vpi.o
verilator -Wall --cc -CFLAGS -fPIC -CFLAGS -DVL_TIME_CONTEXT and_gate.v --Mdir obj_dir
- V e r i l a t i o n   R e p o r t: Verilator 5.026 2024-06-15 rev UNKNOWN.REV
- Verilator: Built from 0.011 MB sources in 2 modules, into 0.025 MB in 7 C++ files needing 0.000 MB
- Verilator: Walltime 0.004 s (elab=0.000, cvt=0.002, bld=0.000); cpu 0.000 s on 1 threads; alloced 7.574 MB
g++ -Wall -g -I/usr/share/verilator/include -I/usr/include/iverilog -Iobj_dir -fPIC -DVL_TIME_CONTEXT -std=c++14 -faligned-new -c and_gate_vpi_wrapper.cpp -o obj_dir/and_gate_vpi_wrapper.o
make -C obj_dir -f Vand_gate.mk
make[1]: Entering directory '/home/kreijstal/git/workspace/bug/obj_dir'
/usr/bin/python3 /usr/share/verilator/bin/verilator_includer -DVL_INCLUDE_OPT=include Vand_gate.cpp Vand_gate___024root__DepSet_h5e7db9b3__0.cpp Vand_gate___024root__DepSet_hb47648ec__0.cpp Vand_gate___024root__Slow.cpp Vand_gate___024root__DepSet_h5e7db9b3__0__Slow.cpp Vand_gate___024root__DepSet_hb47648ec__0__Slow.cpp Vand_gate__Syms.cpp > Vand_gate__ALL.cpp
g++ -Os  -I.  -MMD -I/usr/share/verilator/include -I/usr/share/verilator/include/vltstd -DVM_COVERAGE=0 -DVM_SC=0 -DVM_TRACE=0 -DVM_TRACE_FST=0 -DVM_TRACE_VCD=0 -faligned-new -fcf-protection=none -Wno-bool-operation -Wno-shadow -Wno-sign-compare -Wno-tautological-compare -Wno-uninitialized -Wno-unused-but-set-parameter -Wno-unused-but-set-variable -Wno-unused-parameter -Wno-unused-variable    -fPIC -DVL_TIME_CONTEXT   -c -o Vand_gate__ALL.o Vand_gate__ALL.cpp
echo "" > libVand_gate.verilator_deplist.tmp
g++ -Os  -I.  -MMD -I/usr/share/verilator/include -I/usr/share/verilator/include/vltstd -DVM_COVERAGE=0 -DVM_SC=0 -DVM_TRACE=0 -DVM_TRACE_FST=0 -DVM_TRACE_VCD=0 -faligned-new -fcf-protection=none -Wno-bool-operation -Wno-shadow -Wno-sign-compare -Wno-tautological-compare -Wno-uninitialized -Wno-unused-but-set-parameter -Wno-unused-but-set-variable -Wno-unused-parameter -Wno-unused-variable    -fPIC -DVL_TIME_CONTEXT   -c -o verilated.o /usr/share/verilator/include/verilated.cpp
g++ -Os  -I.  -MMD -I/usr/share/verilator/include -I/usr/share/verilator/include/vltstd -DVM_COVERAGE=0 -DVM_SC=0 -DVM_TRACE=0 -DVM_TRACE_FST=0 -DVM_TRACE_VCD=0 -faligned-new -fcf-protection=none -Wno-bool-operation -Wno-shadow -Wno-sign-compare -Wno-tautological-compare -Wno-uninitialized -Wno-unused-but-set-parameter -Wno-unused-but-set-variable -Wno-unused-parameter -Wno-unused-variable    -fPIC -DVL_TIME_CONTEXT   -c -o verilated_threads.o /usr/share/verilator/include/verilated_threads.cpp
echo "" > libverilated.verilator_deplist.tmp
echo "" > Vand_gate__ALL.verilator_deplist.tmp
rm Vand_gate__ALL.verilator_deplist.tmp libVand_gate.verilator_deplist.tmp libverilated.verilator_deplist.tmp
make[1]: Leaving directory '/home/kreijstal/git/workspace/bug/obj_dir'
g++ -shared -o and_gate_vpi.vpi obj_dir/and_gate_vpi.o obj_dir/and_gate_vpi_wrapper.o obj_dir/Vand_gate__ALL.o obj_dir/libverilated.a -L/usr/share/verilator/include -L/usr/include/iverilog/../lib -L./obj_dir -L/usr/include/iverilog/../lib -lvpi -lveriuser -lverilated -lpthread -lvpi
iverilog -o and_gate_tb.vvp -m./and_gate_vpi.vpi and_gate_proxy.v and_gate_tb.v
vvp -M. -mand_gate_vpi and_gate_tb.vvp
PASS: a=0, b=0, y=0
PASS: a=0, b=1, y=0
PASS: a=1, b=0, y=0
PASS: a=1, b=1, y=1
All tests passed!
and_gate_tb.v:53: $finish called at 114000 (1ps)

On windows however

IVERILOG_DIR = /ucrt64
VPI_INCLUDE_DIR = /ucrt64/include/iverilog
mkdir obj_dir
gcc -Wall -g -I/ucrt64/share/verilator/include -I/ucrt64/include/iverilog -Iobj_dir -fPIC -DVL_TIME_CONTEXT -I/ucrt64/include/iverilog  -c and_gate_vpi.c -o obj_dir/and_gate_vpi.o
verilator -Wall --cc -CFLAGS -fPIC -CFLAGS -DVL_TIME_CONTEXT and_gate.v --Mdir obj_dir
- V e r i l a t i o n   R e p o r t: Verilator 5.026 2024-06-15 rev UNKNOWN.REV
- Verilator: Built from 0.012 MB sources in 2 modules, into 0.025 MB in 7 C++ files needing 0.000 MB
- Verilator: Walltime 0.043 s (elab=0.000, cvt=0.000, bld=0.000); cpu 0.000 s on 1 threads; alloced 10.680 MB
The system cannot find the path specified.
g++ -Wall -g -I/ucrt64/share/verilator/include -I/ucrt64/include/iverilog -Iobj_dir -fPIC -DVL_TIME_CONTEXT -std=c++14 -faligned-new -c and_gate_vpi_wrapper.cpp -o obj_dir/and_gate_vpi_wrapper.o
In file included from E:/msys64/ucrt64/share/verilator/include/verilated.h:42,
                 from obj_dir/Vand_gate.h:11,
                 from and_gate_vpi_wrapper.cpp:2:
E:/msys64/ucrt64/share/verilator/include/verilatedos.h:335:10: warning: "__USE_MINGW_ANSI_STDIO" redefined
  335 | # define __USE_MINGW_ANSI_STDIO 1  // Force old MinGW (GCC 5 and older) to use C99 formats
      |          ^~~~~~~~~~~~~~~~~~~~~~
In file included from E:/msys64/ucrt64/include/corecrt.h:10,
                 from E:/msys64/ucrt64/include/crtdefs.h:10,
                 from E:/msys64/ucrt64/include/stdint.h:28,
                 from E:/msys64/ucrt64/lib/gcc/x86_64-w64-mingw32/14.1.0/include/stdint.h:9,
                 from and_gate_vpi_wrapper.h:4,
                 from and_gate_vpi_wrapper.cpp:1:
E:/msys64/ucrt64/include/_mingw.h:434:9: note: this is the location of the previous definition
  434 | #define __USE_MINGW_ANSI_STDIO 0      /* was not defined so it should be 0 */
      |         ^~~~~~~~~~~~~~~~~~~~~~
make -C obj_dir -f Vand_gate.mk
make[1]: Entering directory '/home/topkek/git/bug/obj_dir'
/ucrt64/bin/python3 E:/msys64/ucrt64/share/verilator/bin/verilator_includer -DVL_INCLUDE_OPT=include Vand_gate.cpp Vand_gate___024root__DepSet_h5e7db9b3__0.cpp Vand_gate___024root__DepSet_hb47648ec__0.cpp Vand_gate___024root__Slow.cpp Vand_gate___024root__DepSet_h5e7db9b3__0__Slow.cpp Vand_gate___024root__DepSet_hb47648ec__0__Slow.cpp Vand_gate__Syms.cpp > Vand_gate__ALL.cpp
g++ -Os  -I.  -MMD -IE:/msys64/ucrt64/share/verilator/include -IE:/msys64/ucrt64/share/verilator/include/vltstd -DVM_COVERAGE=0 -DVM_SC=0 -DVM_TRACE=0 -DVM_TRACE_FST=0 -DVM_TRACE_VCD=0 -faligned-new -fcf-protection=none -Wno-bool-operation -Wno-shadow -Wno-sign-compare -Wno-tautological-compare -Wno-uninitialized -Wno-unused-but-set-parameter -Wno-unused-but-set-variable -Wno-unused-parameter -Wno-unused-variable    -fPIC -DVL_TIME_CONTEXT   -c -o Vand_gate__ALL.o Vand_gate__ALL.cpp
echo "" > libVand_gate.verilator_deplist.tmp
g++ -Os  -I.  -MMD -IE:/msys64/ucrt64/share/verilator/include -IE:/msys64/ucrt64/share/verilator/include/vltstd -DVM_COVERAGE=0 -DVM_SC=0 -DVM_TRACE=0 -DVM_TRACE_FST=0 -DVM_TRACE_VCD=0 -faligned-new -fcf-protection=none -Wno-bool-operation -Wno-shadow -Wno-sign-compare -Wno-tautological-compare -Wno-uninitialized -Wno-unused-but-set-parameter -Wno-unused-but-set-variable -Wno-unused-parameter -Wno-unused-variable    -fPIC -DVL_TIME_CONTEXT   -c -o verilated.o E:/msys64/ucrt64/share/verilator/include/verilated.cpp
g++ -Os  -I.  -MMD -IE:/msys64/ucrt64/share/verilator/include -IE:/msys64/ucrt64/share/verilator/include/vltstd -DVM_COVERAGE=0 -DVM_SC=0 -DVM_TRACE=0 -DVM_TRACE_FST=0 -DVM_TRACE_VCD=0 -faligned-new -fcf-protection=none -Wno-bool-operation -Wno-shadow -Wno-sign-compare -Wno-tautological-compare -Wno-uninitialized -Wno-unused-but-set-parameter -Wno-unused-but-set-variable -Wno-unused-parameter -Wno-unused-variable    -fPIC -DVL_TIME_CONTEXT   -c -o verilated_threads.o E:/msys64/ucrt64/share/verilator/include/verilated_threads.cpp
echo "" > libverilated.verilator_deplist.tmp
echo "" > Vand_gate__ALL.verilator_deplist.tmp
rm Vand_gate__ALL.verilator_deplist.tmp libVand_gate.verilator_deplist.tmp libverilated.verilator_deplist.tmp
make[1]: Leaving directory '/home/topkek/git/bug/obj_dir'
g++ -shared -o and_gate_vpi.vpi obj_dir/and_gate_vpi.o obj_dir/and_gate_vpi_wrapper.o obj_dir/Vand_gate__ALL.o obj_dir/libverilated.a -L/ucrt64/share/verilator/include -L/ucrt64/../lib -L./obj_dir -L/ucrt64/lib -lvpi -lveriuser -lverilated -lpthread -lvpi
iverilog -o and_gate_tb.vvp -m./and_gate_vpi.vpi and_gate_proxy.v and_gate_tb.v
vvp -M. -mand_gate_vpi and_gate_tb.vvp
PASS: a=0, b=0, y=0
PASS: a=0, b=1, y=0
PASS: a=1, b=0, y=0
PASS: a=1, b=1, y=1
All tests passed!
and_gate_tb.v:53: $finish called at 114000 (1ps)

But vvp hangs forever! infinite loop?

[caryr]

If you put in an RTL proxy for the AND gate does it work as expected on windows?

Do you know that the missing path message is benign?

Also, USE_MINGW_ANSI_STDIO is only needed for the msys2 environments that link against MSVCRT. The ucrt64 environment uses, as the name implies, UCRT which does not have the stdio limitations that the mingw environment works around when __USE_MINGW_ANSI_STDIO is used. The downside is UCRT is only installed on windows 10 and later by default. I am working on updates for Icarus where it only uses USE_MINGW_ANSI_STDIO for the environments that use MSVCRT.

[caryr]

Another thought, can you use gdb to detect where things are hanging?

[Kreijstal]

Another thought, can you use gdb to detect where things are hanging?

I am incompetent with gdb but this is my experience:

topkek@ayylmai UCRT64 ~/git/AND-gate-cosim-madness/verilator_vpi_iverilogtb
# gdb --args vvp -M. -mand_gate_vpi and_gate_tb.vvp
GNU gdb (GDB) 15.1
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vvp...
(No debugging symbols found in vvp)
(gdb) run
Starting program: E:\msys64\ucrt64\bin\vvp.exe -M. -mand_gate_vpi and_gate_tb.vvp
[New Thread 11848.0x3740]
[New Thread 11848.0x38a8]
[New Thread 11848.0xfcc]
[New Thread 11848.0x33dc]
[New Thread 11848.0x30c4]
[New Thread 11848.0x1f9c]
PASS: a=0, b=0, y=0
PASS: a=0, b=1, y=0
PASS: a=1, b=0, y=0
PASS: a=1, b=1, y=1
All tests passed!
../common/and_gate_tb.v:53: $finish called at 114000 (1ps)
[New Thread 11848.0x28e0]
[New Thread 11848.0x2c8c]
[New Thread 11848.0x1340]
[New Thread 11848.0x610]
[New Thread 11848.0x33fc]
[New Thread 11848.0x1610]
[New Thread 11848.0x2074]
[New Thread 11848.0x3248]
[Thread 11848.0xfcc exited with code 0]
[Thread 11848.0x3740 exited with code 0]
[Thread 11848.0x38a8 exited with code 0]
[New Thread 11848.0x3230]

after "../common/and_gate_tb.v:53: $finish called at 114000 (1ps)" I tried to ctrl+c, various times to type bt, but it just creates new threads and blocks me from finding the backtrace lol, every tme I type ctrl+c, a new thread gets spawned. [New Thread 11848.0x28e0].

[caryr]

That's likely a clue. Do we need to have verilator installed to test this or are the files you provided enough to reproduce? I assume we need verilator for header files, etc. Since GDB is not working I think we'll have to insert debug print statements at various places in the exit code to figure out where things break. I'm busy for a while so will not have time to do this myself until later.

[Kreijstal]

Yes verilator is necessary is essentially a verilator compiled AND gate simulated through VPI, in Windows I simply use msys2 packaged verilator

[caryr]

I tried to install verilator to see if I could get an environment that reproduced the issue:

pacman -S mingw-w64-ucrt-x86_64-verilator

then tried verilator and it fails:

$ verilator --version
Can't exec "C:/msys64/ucrt64/bin/../share/verilator/bin/verilator": No such file or directory at C:/
msys64/ucrt64/bin/verilator line 21.
%Error: Exec failed, at C:/msys64/ucrt64/bin/verilator line 22.

Running it directly from the share directory seems to work:

$ C:/msys64/ucrt64/bin/../share/verilator/bin/verilator --version
The system cannot find the path specified.
Verilator 5.026 2024-06-15 rev UNKNOWN.REV

any ideas? I don't really have time to debug why verilator is failing. There were other issues, but I think they are all related (e.g. --help failed out of share).

[Kreijstal]

Oh I'm not the only one, how are you running verilator from? Are you using normal windows terminal? I'll make a big report to msys and probably to verilator, I had a similar issue but only when sshing into Windows not when running it from the GUI terminal

when running from GUI terminal there seems to be no problem

[Kreijstal]

The system cannot find the path specified.

Yeah we get the same error.. I'll just report it to msys2

I used this workaround https://github.com/verilator/verilator/commit/f56f3182176c967d9f14861e38563177ab2295f0#commitcomment-145180536 I'm sorry you got hit with this bug as well.. I guess this is also a verilator/msys2 bug :(

[caryr]

I'm working directly on the machine and using the MSYS2 UCRT64 configured shell from the install. I'm able to build iverilog from source and test it so I assume things are configured correctly.

This seems like it could be an exec issue in perl?

Here's the message when I try to run --help using the executable in share:

$ /ucrt64/share/verilator/bin/verilator --help
'C:\msys64\ucrt64\bin\core_perl\perldoc' is not recognized as an internal or external command,
operable program or batch file.
more: stat of /e failed: No such file or directory

perldoc is located at the path specified.

[Kreijstal]

Are you running windows 11?

[caryr]

Nope, still running 10 on this particular machine.

[Kreijstal]

reported, https://github.com/msys2/MINGW-packages/issues/21706 thank you

[caryr]

FYI the following are the steps I did to generate the UCRT64 environment that is failing to run verilator:

Install msys2 Update msys2: pacman -Suy pacman -S git pacman -S bison pacman -S flex pacman -S libreadline-devel pacman -S man-db pacman -S vim

pacman -S mingw-w64-ucrt-x86_64-gcc pacman -S mingw-w64-ucrt-x86_64-gperf pacman -S mingw-w64-ucrt-x86_64-readline pacman -S mingw-w64-ucrt-x86_64-autotools pacman -S mingw-w64-ucrt-x86_64-ghostscript pacman -S mingw-w64-ucrt-x86_64-perl pacman -S mingw-w64-ucrt-x86_64-python-pip pacman -S mingw-w64-ucrt-x86_64-verilator

[caryr]

There was an update to the msys2 verilator that now allows me to run the test. During debugging I ran into a couple issues.

You do not need the -M or -m options you are passing to vvp since you are already passing that to iverilog and it is in turn passing it in the compiler output.

The real issue appears to be that windows is hanging while trying to unload the AND DLL. This is outside iverilog so I'm not certain what to do. It likely will require more debug and it does work correctly for the iverilog DLLs so it's likely something related to the way you are building the DLL from verilator

Here's a simple patch that I used to show which DLLs are loaded and their address and then which DLL is being closed. It clearly shows the system hanging while trying to unload the AND gate DLL.

diff --git a/vvp/vpi_modules.cc b/vvp/vpi_modules.cc
index 6c96ad7d3..114f587b1 100644
--- a/vvp/vpi_modules.cc
+++ b/vvp/vpi_modules.cc
@@ -135,6 +135,7 @@ void vpip_add_env_and_default_module_paths()
 void load_module_delete(void)
 {
       for (unsigned idx = 0; idx < dll_list_cnt; idx += 1) {
+           fprintf(stderr, "Closing DLL: %p\n", dll_list[idx]);
            ivl_dlclose(dll_list[idx]);
       }
       free(dll_list);
@@ -247,6 +248,7 @@ void vpip_load_module(const char*name)
            ivl_dlclose(dll);
            return;
       }
+      fprintf(stderr, "Adding DLL: %s - %p\n", name, dll);

        /* Add the dll to the list so it can be closed when we are done. */
       dll_list_cnt += 1;

$  make
IVERILOG_DIR = /ucrt64
VPI_INCLUDE_DIR = /ucrt64/include/iverilog
vvp and_gate_tb.vvp
Adding DLL: .\and_gate_vpi.vpi - 00007ffe94e20000
Adding DLL: C:\msys64\ucrt64\lib\ivl\system.vpi - 00007ffe887c0000
Adding DLL: C:\msys64\ucrt64\lib\ivl\vhdl_sys.vpi - 00007ffed3f20000
Adding DLL: C:\msys64\ucrt64\lib\ivl\vhdl_textio.vpi - 00007ffeb7a60000
Adding DLL: C:\msys64\ucrt64\lib\ivl\v2005_math.vpi - 00007ffec49e0000
Adding DLL: C:\msys64\ucrt64\lib\ivl\va_math.vpi - 00007ffec41a0000
PASS: a=0, b=0, y=0
PASS: a=0, b=1, y=0
PASS: a=1, b=0, y=0
PASS: a=1, b=1, y=1
All tests passed!
and_gate_tb.v:53: $finish called at 114000 (1ps)
Closing DLL: 00007ffe94e20000

[caryr]

Also, we recommend using iverilog-vpi to generate DLLs that are compatible with iverilog. I understand this is likely not possible for this endeavor, but make sure you are matching what iverilog-vpi would do as closely as possible and that may resolve the issue.

[caryr]

Some searching shows that if the DLL is waiting on process input it will hang so maybe you need to create an EndOfSimulation call back to make sure everything in the DLL is shutdown and cleaned up correctly so it can be closed correctly. Linux likely just forces everything to close, though if you run valgrind it will likely show memory that was not freed correctly at exit.

If you can find something that indicates this is an iverilog issue please let us know. I marked this Need info since it is likely an issue in the DLL code.

[Kreijstal]

There was an update to the msys2 verilator that now allows me to run the test. During debugging I ran into a couple issues.

Ah yes that was me, my "fix" was to use cygwin perl instead of native windows perl, no one was happy with that, but it seemed to solve the problem for the short term.

Also, we recommend using iverilog-vpi to generate DLLs that are compatible with iverilog. I understand this is likely not possible for this endeavor, but make sure you are matching what iverilog-vpi would do as closely as possible and that may resolve the issue.

I tried to use iverilog-vpi while that worked for linux, on windows it refused to accept other files external to it, like headers, or external .dlls 🤷 on windows so I tried to do it myself.

Hmm you are saying this could be a verilator bug on windows? It seems however that when I only use verilator, there is no issue unloading the dll? I have to say thank you for looking into this. Thank you so much.

[caryr]

FYI verilator --help still fails, but at least I can run your example after the update.

iverilog-vpi is a separate program for windows where it is a script for all other systems. It's possible the program needs some improvements.

I'm not sure I would call this a verilator bug, but does verilator use different functions to load and unload the DLLs on windows? Or maybe it does something different in how the DLLs are used/interact with the rest of the code (e.g. callbacks). There is likely something subtle in the generated code where it works as expected using the verilator flow, but fails in iverilog because it has a slightly different flow.

[Kreijstal]

FYI verilator --help still fails, but at least I can run your example after the update.

Thank you, I'll take a look at it when I have time.

I am not a verilator dev, so not sure about how the verilator flow works exactly, maybe I just need to spend more time fiddling with things.

[caryr]

Can you file a PR against verilator that is linked to this one and maybe we can get some collaboration from the verilator team to resolve this issue. I do find the idea of linking the two tools interesting.

Though a detailed description of what you did to link the tools is a good place to start so we can understand what is verilator generated code, what is wrapper code, how you created the linking of the inputs, outputs, etc. My guess is it's the linking code that is still active and preventing the DLL from closing correctly.

[caryr]

Any progress seeing if there is custom code or verilator generated code that is causing the DLL to not be closed correctly?

[Kreijstal]

Hi, I'll work on it, Thanks for the reminder

[Kreijstal]

Hello, so I tried to use master branch instead of the release branch and I get the following error while executing vvp:

verilate initialize
create Vand gate verilator
sorry: vpi_handle_multi currently supportsonly vpiInterModPath
VPI error: vpi_handle(type=89, ref=0).
Assertion failed: expr, file ../../iverilog/vvp/vpi_priv.cc, line 1842

Any ideas?

[caryr]

This was code added by our GSOC student last year. It's possible this was just ignored previously. I would need to look at the development code in more detail to know how to work around this. Do you have a code snippet for this or is it in the code you originally provided?

[caryr]

I looked at the standard quickly and it looks like vpi_handle_multi() is intended to only find objects of type vpiInterModPath so what is the type you are passing? Next it looks like you are not checking the value returned by vpi_handle_multi() which is returning NULL for this case. You are then passing the NULL to vpi_handle() asking for the vpiArgument and this is asserting since you have a NULL reference handle. This looks like coding errors on your side.