[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gEDA-user: Icarus bug?



Hi,

On Tue, 2007-05-15 at 15:47 -0700, Benjamin Ylvisaker wrote:
> I believe I found a bug in the Icarus VPI implementation, but I wanted
> to check before filing a bug report.
> 
> I have code that works with ModelSim under Linux, but I want to
> develop on my primary computer, which is a PowerBook, so I'm trying to
> get it working with Icarus under OS X.  Here's the troublesome bit:
> 
> void register() {
>   s_cb_data init;
>   vpiHandle cbHandle;
> 
>   init.reason = cbStartOfSimulation;
>   init.cb_rtn = initializeSim;
>   init.obj = NULL;
>   init.time = NULL;
>   init.value = NULL;
>   init.user_data = NULL;
> 
>   cbHandle = vpi_register_cb(&init);
> /*  vpi_free_object(cbHandle);*/
> }
> 
> void (*vlog_startup_routines[ ] ) () = {
>    register,
>    0
> };
> 

Be careful here, you are passing a pointer to an auto variable into the
vpi_register() function.  The lifetime of the variable may need to be
longer than the end of your function.  The Verilog standard itself is
pretty loosy-goosy on the subject of who allocates and frees these
things.

I'd recommend declaring the 'init' as:

static s_cb_data init;

instead.  Also, anything that the structure refers to should also be
declared static, or malloc()'ed.  In fact, all of the examples in the
Verilog standard follow this 'static' convention.

> When I run it this way, it seems to work okay, but when I uncomment
> the call to "vpi_free_object", it causes Icarus to crash with a "Bus
> Error".  The Verilog PLI Handbook says that it's good style to free
> the callback handle, unless you need to use it somewhere else.

It might not be a good idea to free the callback object yet, since the
callback has not happened. The example in the Verilog standard does not
free the object either.

Normally you use the vpi_free*() functions to free things that are
returned to you from the simulator kernel.

> 
> Does this look like a bug to anyone else?

In some ways, yes.  But it looks like a classic auto variable that gets
a pointer dereference that leads to a bus error, or worse, random stack
trampling.  Those bugs are the most fun to find.

> 
> Benjamin
> 
> 
> _______________________________________________
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
> 
-- 
--------------------------------------------------
                                      Mike Jarabek
         FPGA/ASIC Designer, DSP Firmware Designer
http://www.sentex.ca/~mjarabek                    
--------------------------------------------------



_______________________________________________
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user