Marlon James

Try setting `COCOTB_LOG_LEVEL=DEBUG`. That will print out more information about VPI accessing the design.

Hmm. For VPI, we are only doing `vpi_handle_by_name` and that is not working for generate handles. For Icarus we do a fallback check when `vpi_handle_by_name` fails, but not for other...

Try running again with `COCOTB_LOG_LEVEL=DEBUG` if you want the additional logging (not `COCOTB_DEBUG_LEVEL`). `TRACE` is really only useful for tracing execution from simulator, through C++ callbacks, to Python, and back...

This line: > `# COUT: 100.00ns DEBUG gpi Searching for i_swapper_vhdl` Is searching by name. I'm interested in the earlier section of the log that might show where this name...

My guess is the segfault is occurring in `VhpiObjHdl::initialise()`. https://github.com/cocotb/cocotb/blob/1ce9390bf7ea270e8ff8c91d436b99236e09ff7b/cocotb/share/lib/vhpi/VhpiCbHdl.cpp#L239-L257

I found that it is being accessed directly by name by the Python test `mixed_language_accessing_test`. I don't have a local setup for debugging Riviera+GPI right now. Would you be able...

If you step through `VhpiObjHdl::initialise()` does it segfault inside the call to `GpiObjHdl::initialise()` or is that from some later point in time?

So I just checked the cocotb extended regression tests and found that in our setup this test passes using the same version of Riviera-PRO: This was run 4 days ago...

The error is in libc `__intf_free()`. > `# COUT: free(): invalid pointer` Here is snippet of the source: ```c static void _int_free (mstate av, mchunkptr p, int have_lock) { INTERNAL_SIZE_T...

> I run Riviera inside docker container based on CentOs 8. What version of cocotb are you using and how did you install it in the container?