[Bug ada/32234] New: Default pointer initialization not occuring - due to the use of <>

[Bug ada/32234] New: Default pointer initialization not occuring - due to the use of <>

[baldrick at gcc dot gnu dot org]

I see this problem with mainline and with GNAT GPL 2007.
A pointer is not being default initialized to NULL in
Ada.Containers.Hashed_Maps.  This causes segmentation faults
on large programs.  On the small testcase (see end of message)
you need valgrind to see it, since almost always you get NULL
by accident.  This problem seems awfully similar to ACT bug
EA23-003.

Note that in Ada.Containers.Hashed_Maps.Insert.New_Node there is
         return new Node_Type'(Key     => Key,
                               Element => <>,
                               Next    => Next);
If I get rid of the <> then the problem goes away.

$ gnatmake -gnat05 p
gcc -c -gnat05 p.adb
gnatbind -x p.ali
gnatlink p.ali
$ valgrind --tool=memcheck ./p
...
==25467== Conditional jump or move depends on uninitialised value(s)
==25467==    at 0x804AA2F: _ada_p (in /home/duncan/Programming/Bugs/bug_103/p)
==25467==    by 0x80497F6: main (in /home/duncan/Programming/Bugs/bug_103/p)

Testcase:
--chop here--
with Ada.Containers.Hashed_Maps;
procedure P is
   function H (I : Integer) return Ada.Containers.Hash_Type is
   begin
      return Ada.Containers.Hash_Type'Mod (I);
   end;
   type Item_Pointer is access Boolean;
   package M is new Ada.Containers.Hashed_Maps (Integer, Item_Pointer, H, "=");
   Z : M.Map;
   Position : M.Cursor;
   Inserted : Boolean;
   Item : Item_Pointer;
begin
   M.Insert (Z, 2, Position, Inserted); -- default initialization for new item
   Item := M.Element (Position);
   if Item = null then -- Item contains a random value here
      Item := new Boolean;
   end if;
end;


-- 
           Summary: Default pointer initialization not occuring - due to the
                    use of <>
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: baldrick at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234

[Bug ada/32234] Default pointer initialization not occuring - due to the use of <>

[anhvofrcaus at gmail dot com]

------- Comment #1 from anhvofrcaus at gmail dot com  2007-06-06 17:44 -------
Why shouldn't it happen in a small program?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234

[Bug ada/32234] Default pointer initialization not occuring - due to the use of <>

[baldrick at gcc dot gnu dot org]

------- Comment #2 from baldrick at gcc dot gnu dot org  2007-06-06 18:35 -------
> Why shouldn't it happen in a small program?

It can cause a segfault also in small programs.
However, memory areas often start out containing
all zeros, so until the program has dirtied a bunch
of memory uninitialized variables tend to contain
zero by accident.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234

[Bug ada/32234] Default pointer initialization not occuring - due to the use of <>

[anhvofrcaus at gmail dot com]

------- Comment #3 from anhvofrcaus at gmail dot com  2007-06-06 20:46 -------
The test code works fine on GNAT-GPL-2007 (Linux and Windows). In addition, it
works fine on Linux with GCC-4.3-2007070518 and GCC-4.3-20070601 also.


-- 

anhvofrcaus at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anhvofrcaus at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234

[Bug ada/32234] Default pointer initialization not occuring - due to the use of <>

[baldrick at gcc dot gnu dot org]

------- Comment #4 from baldrick at gcc dot gnu dot org  2007-06-06 20:59 -------
You have to run it under valgrind to see the problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234

[Bug ada/32234] Default pointer initialization not occuring - due to the use of <>

[anhvofrcaus at gmail dot com]

------- Comment #5 from anhvofrcaus at gmail dot com  2007-06-06 23:27 -------
Valgrind is helful only if there is a crash (segmentation fault). However,
there is no seg fault when executed in this case. Therefore, there would be
exclusive conclusion.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234

[Bug ada/32234] Default pointer initialization not occuring - due to the use of <>

[anhvofrcaus at gmail dot com]

------- Comment #6 from anhvofrcaus at gmail dot com  2007-06-06 23:29 -------
Oop! I meant inclusive conclusion.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234

[Bug ada/32234] Default pointer initialization not occuring - due to the use of <>

[baldrick at gcc dot gnu dot org]

------- Comment #7 from baldrick at gcc dot gnu dot org  2007-06-07 07:07 -------
> Valgrind is helful only if there is a crash (segmentation fault).

This is completely wrong.  Valgrind detects problems that *may*
cause a crash.  The fact that crashes occur rarely doesn't mean
there isn't something wrong.  I already explained that you can't
expect to get a segmentation fault on a small program.  So for a
testcase I either had to provide the large (300k/loc) original
program which showed the segmentation fault systematically,
or a small program which basically never shows a segmentation
fault.  i.e. testcases become less and less deterministic as you
make them smaller.  However there is a way to keep things
deterministic: run under a tool such as valgrind.  Valgrind detects
the same problem every time no matter how big or small the testcase.
This makes it feasible to submit a minimal testcase which captures
the essential problem, even though when run normally (i.e. not under
valgrind) it executes fine.  In fact you will never get a segmentation
fault with the testcase I submitted because it doesn't ever dereference
the uninitialized pointer - but that doesn't matter because valgrind
notices that it contains an uninitialized value when the "if" compares
it with null. i.e. the testcase is good enough for debugging the compiler
problem.

Let me say it again: when run on the small testcase valgrind shows
the presence of an uninitialized value that doesn't cause any problems
when the small testcase is run - it causes problems on the large
program from which this testcase was reduced.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234

[Bug ada/32234] [Ada] Default pointer initialization not occuring - due to the use of <>

[laurent at guerby dot net]

------- Comment #8 from laurent at guerby dot net  2007-06-07 19:43 -------
Here is a test case that's likely to fail: I just allocate a non zero filled
record of the right size before filling the map.

Expects no output, but will raise program_error because of the bug (with 4.3.0
20070606 on x86_64-linux).

$ gnatmake -g p; ./p
gcc -c -g p.adb
gnatbind -x p.ali
gnatlink p.ali -g

raised PROGRAM_ERROR : p.adb:27 explicit raise

$ cat p.adb
with Ada.Unchecked_Deallocation;
with Ada.Containers.Hashed_Maps;
procedure P is
   function H (I : Integer) return Ada.Containers.Hash_Type is
   begin
      return Ada.Containers.Hash_Type'Mod (I);
   end;
   type Item_Pointer is access Boolean;
   type R is record
      X,Y,Z : Integer := 5;
   end record;
   type R_Ptr is access R;
   RR : R_Ptr := new R;
   procedure Free is new Ada.Unchecked_Deallocation (R, R_Ptr);


   package M is new Ada.Containers.Hashed_Maps (Integer, Item_Pointer, H, "=");
   Z : M.Map;
   Position : M.Cursor;
   Inserted : Boolean;
   Item : Item_Pointer;
begin
   Free (RR);
   M.Insert (Z, 2, Position, Inserted); -- default initialization for new item
   Item := M.Element (Position);
   if Item /= null then -- Item contains a random value here
      raise Program_Error;
   end if;
end;


-- 

laurent at guerby dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |laurent at guerby dot net
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2007-06-07 19:43:14
               date|                            |
            Summary|Default pointer             |[Ada] Default pointer
                   |initialization not occuring |initialization not occuring
                   |- due to the use of <>      |- due to the use of <>


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234

[Bug ada/32234] [Ada] Default pointer initialization not occuring - due to the use of <>

[baldrick at gcc dot gnu dot org]

------- Comment #9 from baldrick at gcc dot gnu dot org  2007-06-07 20:12 -------
> Here is a test case that's likely to fail: I just allocate a non zero filled
> record of the right size before filling the map.

Good idea - thanks for doing this!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234

[Bug ada/32234] [Ada] Default pointer initialization not occuring - due to the use of <>

[anhvofrcaus at gmail dot com]

------- Comment #10 from anhvofrcaus at gmail dot com  2007-06-08 01:10 -------
Thank you both for your explanation to a newbie having no experience with
valgrind tool. I have come up with a simpler version which similar to
Laurent's. Here it goes.

with Ada.Containers.Hashed_Maps;
procedure P is
  function H (I : Integer) return Ada.Containers.Hash_Type is
  begin
     return Ada.Containers.Hash_Type'Mod (I);
  end;
  type Item_Pointer is access Boolean;

  package M is new Ada.Containers.Hashed_Maps (Integer, Item_Pointer, H, "=");
  Z : M.Map;
  Position : M.Cursor;
  Inserted : Boolean;
  Item : Item_Pointer;
begin
  M.Insert (Z, 2, Position, Inserted); -- default initialization for new item
  Item := M.Element (Position);
  if not Item.all'Valid then -- equivalent to Item /= null if check
     raise Program_Error with "Failing test";
  end if;
end P;


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234

[Bug ada/32234] [Ada] Default pointer initialization not occuring - due to the use of <>

[baldrick at gcc dot gnu dot org]

------- Comment #11 from baldrick at gcc dot gnu dot org  2007-06-08 18:46 -------
> Thank you both for your explanation to a newbie having no experience with
> valgrind tool. I have come up with a simpler version which similar to
> Laurent's. Here it goes.

Thanks - but how is it supposed to work?  You didn't dirty memory
like Laurent did (new+free), so Item will contain null and you'll
get a constraint error in Item.all'Valid.  [If you are very lucky
Item will contain a non-zero value and you will get a segmentation
fault].  I just ran your example a few thousand times and never
saw anything besides constraint error.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234

[Bug ada/32234] [Ada] Default pointer initialization not occuring - due to the use of <>

[anhvofrcaus at gmail dot com]

------- Comment #12 from anhvofrcaus at gmail dot com  2007-06-08 19:11 -------
You are right Constraint_Error is raised when checking for validity through
Item.all'Valid if Item is null. Therefore, using Laurent's to check Item for
null is the only way. Either one of these methods verifies that the bug exists. 

In summary, the program, small or large, behaves the same way although it is an
undersired behavior in this case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234

[Bug ada/32234] [Ada] Default pointer initialization not occuring - due to the use of <>

[baldrick at gcc dot gnu dot org]

------- Comment #13 from baldrick at gcc dot gnu dot org  2008-03-28 14:30 -------
This has been fixed.


-- 

baldrick at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234