comp.lang.ada
 help / color / mirror / Atom feed
From: "Steven Deller" <deller@smsail.com>
To: <comp.lang.ada@ada.eu.org>
Subject: RE: compiler bug or me being stupid? (ok, probably the later :)
Date: Fri, 4 Jan 2002 12:08:46 -0500
Date: 2002-01-04T12:08:46-05:00	[thread overview]
Message-ID: <mailman.1010164262.25860.comp.lang.ada@ada.eu.org> (raw)
In-Reply-To: <a0ckeg$cfj$1@inf6serv.rug.ac.be>

Stijn,
On Apex 4.0 this acts similarly to your cases, except the exception that
is raised is
  PROGRAM_ERROR
in all cases.

I believe you are raising an exception in one of the
Initialize/Adjust/Finalize routines and failing to handle it there
(probably in Finalize, given your outputs).  The result is an error (ARG
is, I believe, trying to decide if it is a bounded error).  

problem_a and problem_c run "to completion" and then raise the error
because, I believe, Finalize is never called until the end.  In
problem_b and problem_d, Finalize is called early.

You are definitely missing something.  I don't have time (unless you
want to pay me :-) ) to debug your problem.

I'd recommend using a debugger and/or adding exception handlers to the
code to figure out what is wrong with your structures.

Regards,
Steven Deller 

> -----Original Message-----
> From: comp.lang.ada-admin@ada.eu.org 
> [mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Stijn Rammeloo
> Sent: Wednesday, December 26, 2001 8:41 AM
> To: comp.lang.ada@ada.eu.org
> Subject: compiler bug or me being stupid? (ok, probably the later :)
> 
> 
> Hello,
> 
> Currently I'm writing a list package that internally uses 
> smart pointers to facilitate structural sharing between 
> different lists. These smart pointers basically free their 
> referent when the reference count drops to zero.
> 
> The basic types (in no particular) order are:
> 
> type Smart_Pointer is new Ada.Finalization.Controlled with  record
>   Referent : Reference_Counted_Element;
>  end record;
> 
> type Reference_Counted_Element_Type is
>  record
>   Referent : Element_Pointer_Type;
>   Counter  : Natural;
>  end record;
> 
> type Reference_Counted_Element is access 
> Reference_Counted_Element_Type;
> 
> type Cell_Type is
>  record
>   Prev : Cell_Pointer;
>   Next : Cell_Pointer;
>   Item : Smart_Pointer;
>  end record;
> 
> type Cell_Pointer is access Cell_Type;
> 
> type List_Type is new Ada.Finalization.Controlled with
>  record
>   Root : Cell_Pointer;
>  end record;
> 
> type Iterator_Type is
>  record
>   Component : List_Type;
>   Current   : Cell_Pointer := null;
>  end record;
> 
> The iterator subprograms defined in rbc-components-lists.ads 
> are exercising odd behavior as can be observed when compiling 
> the testprograms problem_a.adb, problem_b.adb problem_c.adb 
> and problem_d.adb included in the attachment (I'm using GNAT 
> 3.13p  (20000509) on a Solaris 2.6 machine as a compiler).
> 
> +++ problem_a.adb
> 
> In this program I use the New_Iterator procedure
>  procedure New_Iterator
>  (List     : in     List_Type;
>  Iterator :    out Iterator_Type);
> 
> Execution of this program gives:
>  10
>  9
>  8
>  7
>  6
>  5
>  4
>  3
>  2
>  1
> got here
> 
> Which is ok.
> 
> +++ problem_b.adb
> 
> In this program I use the New_Iterator function instead of 
> the New_Iterator procedure (they basically do the same 
> thing). function New_Iterator  (List : List_Type)  return 
> Iterator_Type;
> 
> execution of this program gives:
> got here
> 
> raised RBC.COMPONENTS.NULL_POINTER_EXCEPTION : 
> rbc-components-smart_pointers.adb:93 instantiated at 
> rbc-components-lists.ads:91 instantiated at problem_support.ads:7
> 
> Which is not ok.
> 
> Closer inspection with the debugger (gvd) revealed that the 
> referent field (of type Reference_Counted_Element) of the 
> item field (of type
> Smart_Pointer) of all list-elements (of type Cell_Type) 
> contains the value null after return of the New_Iterator 
> function while they where non-null in the iterator function 
> just before the return. Is the compiler missing something or 
> did I overlooked something happening as a side effect of the 
> Initialize, Adjust and Finalize routines for the types 
> Smart_Pointer and List_Type during the return?
> 
> ++ problem_c.adb
> This program is similar to problem_a.adb except that i'm now 
> allocating 20 items instead of 10 (a quite modest number :).
> 
> execution of this program gives:
> 
> 20
> 19
> 18
> .
> .
> .
>  3
>  2
>  1
> got here
> 
> raised PROGRAM_ERROR : rbc-components-lists.ads:101
> 
> Which is not Ok.
> 
> It is kind of odd because the Put_Line statement printing 
> 'got here' is the last line in the program. If I run this 
> program in the debugger I get more detailed error information:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x2bb90 in system__finalization_implementation__finalize_one ()
> 
> ++ problem_D.adb
> This program is like problem_b.adb except that i'm again 
> allocating 20 items instead of 10.
> 
> execution of this program gives:
> 
> next line is causing trouble
> 
> raised PROGRAM_ERROR : rbc-components-lists.ads:101
> 
> Eg. the exception is now raised in the New_Iterator function.
> 
> Running the program in the debugger returns a similar problem 
> description as for problem_c.adb:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x2c024 in system__finalization_implementation__finalize_one ()
> 
> Apparently, the compiler (or my brain :) has problems 
> automatically allocating/freeing the resources attached to an 
> Iterator object. If I only create a list, populate it 
> (1000000 elements) and remove all the elements again the 
> program completes successfully, From the moment I create and 
> use an Iterator, I'm in trouble.
> 
> 
> Compiling the different programs with jgnat removes the 
> problems asociated with the allocation of 20 objects (eg 
> Segmentation Fault) but the Null_Pointer_Exception still 
> remains. Compiling the different programs with ObjectAda 
> version 7.2.1 throws in all 4 cases a Program_Error.
> 
> 
> Can some of the Ada-gurus out there
> a) try to compile with still a different Ada-95 compiler 
> (preferably gnat 1.14).
> b) take a look at the code and explain me where I'm wrong.
> c) say some supportive words because I'm definitely reaching 
> the point where I need some Prozac :)
> 
> Thanks in foresee,
> Stijn
> __________________________________________________
> Rammeloo Stijn
> Development Engineer Software
> BarcoView - Avionics
> Th. Sevenslaan 106,   B-8500 Kortrijk, BELGIUM
> Tel. +32 56 233984,   Fax +32 56 233588
> Email : mailto:stijn.rammeloo@barco.com
> Visit our website : http://www.barcoview.com
> 
> 
> 




      parent reply	other threads:[~2002-01-04 17:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <a0ckeg$cfj$1@inf6serv.rug.ac.be>
2001-12-26 15:54 ` compiler bug or me being stupid? (ok, probably the later :) James Rogers
2002-01-04 17:08 ` Steven Deller [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox