comp.lang.ada
 help / color / mirror / Atom feed
* Re: compiler bug or me being stupid? (ok, probably the later :)
       [not found] <a0ckeg$cfj$1@inf6serv.rug.ac.be>
@ 2001-12-26 15:54 ` James Rogers
  2002-01-04 17:08 ` Steven Deller
  1 sibling, 0 replies; 2+ messages in thread
From: James Rogers @ 2001-12-26 15:54 UTC (permalink / raw)


Without a look at your actual code I can only guess.

My first guess is that your finalize and adjust procedures may need some
inspection. Some of your errors indicate a possible attempt to 
deallocate from a null access value. Make sure your finalize procedure 
checks for a null access value and does not call your deallocation 
routine if the access element is null.

Your problem with the differences between the procedure call and the
function call are not entirely a surprise. Again, look at the adjust
procedure for your Smart_Pointer type. A function return value
requires copy semantics to work properly. A procedure IN OUT
parameter can do its work by reference.

Jim Rogers
Colorado Springs, Colorado USA



^ permalink raw reply	[flat|nested] 2+ messages in thread

* RE: compiler bug or me being stupid? (ok, probably the later :)
       [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
  1 sibling, 0 replies; 2+ messages in thread
From: Steven Deller @ 2002-01-04 17:08 UTC (permalink / raw)
  To: comp.lang.ada

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
> 
> 
> 




^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-01-04 17:08 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox