Bug#574597: [ghdl] Uninitialized generics can make ghdl trying to eat a huge amount of memory during simulation, making then the whole system hang

[Baggett Jonas]

Package: ghdl
Version: 0.29+gcc4.3.4+dfsg-1
Severity: serious

--- Please enter the report below this line. ---

Hi

I noticed that ghdl check for uninitialized generics that are defined
in the top level only.

In this example there is an uninitialized generic which is defined in
the top level :

jo...@pc:~/a$ ghdl -a good.vhd
jo...@pc:~/a$ ghdl -e tb
error: entity "tb" cannot be at the top of a design
good.vhd:16:13: (generic "n_bits_data" has no default value)
/usr/lib/ghdl/bin/ghdl: compilation error
jo...@pc:~/a$

Then ghdl rightly complains during the elaboration.

But when there is a generic that isn't defined in the top level, ghdl
won't check if it is initialized or not.

See the following example :

jo...@pc:~/a$ ghdl -a bad.vhd
jo...@pc:~/a$ ghdl -e tb
Here ghdl should complain that there is an uninitialized generic, but
it doesn't because the generic is not defined in the top level.
jo...@pc:~/a$ ghdl -r tb
Now ghdl is trying to eat a huge amount of memory and I quickly have to
kill it before the whole system hangs !!!!

There is more explanations in the examples (put in attachement)
Bye
Jonas


--- System information. ---
Architecture: i386
Kernel:       Linux 2.6.32-3-686

Debian Release: squeeze/sid
  500 testing         ftp.de.debian.org 
  111 unstable        ftp.de.debian.org 
  110 experimental    ftp.de.debian.org 

--- Package information. ---
Depends             (Version) | Installed
=============================-+-=============
libc6                (>= 2.7) | 2.10.2-6
libgcc1          (>= 1:4.1.1) | 1:4.4.2-9
libgmp3c2                     | 2:4.3.2+dfsg-1
libgnat-4.4      (>= 4.4.3-1) | 4.4.3-1
libmpfr1ldbl                  | 2.4.2-3
gnat-4.4                      | 4.4.3-1
zlib1g-dev                    | 1:1.2.3.4.dfsg-3


Recommends      (Version) | Installed
=========================-+-===========
gtkwave                   | 3.3.3-1


Package's Suggests field is empty.






-- 
 <poubl...@laposte.net>

library ieee;
use ieee.std_logic_1164.all;

-- COMPONENT
entity a is
   generic (N_BITS_DATA : integer);
end entity;

architecture arch_a of a is
begin
end;
--

-- TESTBENCH
entity tb is
   generic (N_BITS_DATA : integer);
end;

architecture arch_tb of tb is
begin
end;
--

library ieee;
use ieee.std_logic_1164.all;

-- COMPONENT
entity a is
   -- N_BITS_DATA is nowhere initialized. This problem should be catched during
   -- elaboration but it isn't !
   -- During simulation I found that the value of N_BITS_DATA is -2147483648 and
   -- that the value of N_BITS_DATA-1 is 2147483647 !!!!
   generic (N_BITS_DATA : integer);
end entity;

architecture arch_a of a is
   --~ -- Here data_s will have 4_194_305 elements and this will make ghdl
   --~ -- take about 650 MB of memory. According to that, each element take about 150 B
   --~ signal data_s : std_logic_vector((N_BITS_DATA-1)/512 downto 0);

   -- This line make ghdl eat all the free memory because it is trying to make a
   -- vector of 2**31 elements !!!! And there isn't enough memory because we need
   -- about 2**31 * 150 B = ~ 300 GB !!!!
   signal data_s : std_logic_vector(N_BITS_DATA-1 downto 0);

   --~ -- Strangely this line doesn't make the simulation failed because N_BITS_DATA
   --~ -- is negativ, but it doesn't increase the use of memory either.
   --~ signal data_s : std_logic_vector(N_BITS_DATA downto 0);
begin
   process begin
      -- N_BITS_DATA = -2147483648 = -2**31
      report integer'image(N_BITS_DATA);
      --
      -- N_BITS_DATA-1 = 2147483647 = 2**31 - 1
      report integer'image(N_BITS_DATA-1);
      --
      -- (N_BITS_DATA-1)/512 = 4_194_304 = 2**22
      report integer'image((N_BITS_DATA-1)/512);
      --
   end process;
end;
--

-- TESTBENCH
entity tb is end entity;

architecture arch_tb of tb is
begin
   X1: entity work.a;
end;
--