Gnat: system__finalization_implementation__finalize_list

Gnat: system__finalization_implementation__finalize_list

[Victor Porton]

Ideas what this means, how to find the error?
(All checks are turned on!)

Program received signal SIGSEGV, Segmentation fault.
0x40164c96 in system__finalization_implementation__finalize_list () from /usr/lib/libgnat-3.14p.so.1

This error appears after exiting my main rountine (well, the main 
rountine is not a procedure but a begin...end block of a package
body.)

Gnat 3.14p, i386/Linux.

Re: Gnat: system__finalization_implementation__finalize_list

[Victor Porton]

In article <3e379038$0$350$bed64819@news.gradwell.net>,
	porton@ex-code.com (Victor Porton) writes:
> Ideas what this means, how to find the error?
> (All checks are turned on!)
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x40164c96 in system__finalization_implementation__finalize_list () from /usr/lib/libgnat-3.14p.so.1
> 
> This error appears after exiting my main rountine (well, the main 
> rountine is not a procedure but a begin...end block of a package
> body.)
> 
> Gnat 3.14p, i386/Linux.

Well, seemingly no this problem with Gnat-3.2. So it maybe is a bug in 
Gnat-3.14p?

Re: Gnat: system__finalization_implementation__finalize_list

[Stephen Leake]

porton@ex-code.com (Victor Porton) writes:

> Ideas what this means, how to find the error?
> (All checks are turned on!)
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x40164c96 in system__finalization_implementation__finalize_list ()
> from /usr/lib/libgnat-3.14p.so.1 

Run under the debugger and trace up the stack.

> This error appears after exiting my main rountine (well, the main
> rountine is not a procedure but a begin...end block of a package
> body.)

That's _not_ a main routine; in Ada, the main routine must be a
library level procedure. Hmm, can't find that in the LRM, maybe that's
a GNAT distinction.

The sequence of statements in a package body is executed at
elaboration time, before the main program's sequence of statements.

-- 
-- Stephe

Re: Gnat: system__finalization_implementation__finalize_list

[Victor Porton]

In article <uhebrvixj.fsf@nasa.gov>,
	Stephen Leake <Stephen.A.Leake@nasa.gov> writes:
> porton@ex-code.com (Victor Porton) writes:
> 
>> Ideas what this means, how to find the error?
>> (All checks are turned on!)
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x40164c96 in system__finalization_implementation__finalize_list ()
>> from /usr/lib/libgnat-3.14p.so.1 
> 
> Run under the debugger and trace up the stack.

It is inside of Ada libraries. To check I would need to download the 
Gnat sources and probably recompile these :-(

Oh, Ada is not so reliable as I cannot find a cause of segfault with 
all checks turned on! :-~ Like C++...

>> This error appears after exiting my main rountine (well, the main
>> rountine is not a procedure but a begin...end block of a package
>> body.)
> 
> That's _not_ a main routine; in Ada, the main routine must be a
> library level procedure. Hmm, can't find that in the LRM, maybe that's
> a GNAT distinction.

"Main rountine" was just my informal wording.

> The sequence of statements in a package body is executed at
> elaboration time, before the main program's sequence of statements.

No main procedure at all in my program.

Re: Gnat: system__finalization_implementation__finalize_list

[Bill Findlay]

On 29/1/03 23:35, in article 3e38664a$0$351$bed64819@news.gradwell.net,
"Victor Porton" <porton@ex-code.com> wrote:

> In article <uhebrvixj.fsf@nasa.gov>,
> Stephen Leake <Stephen.A.Leake@nasa.gov> writes:
>> porton@ex-code.com (Victor Porton) writes:
>> 
>>> Ideas what this means, how to find the error?
>>> (All checks are turned on!)
>>> 
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x40164c96 in system__finalization_implementation__finalize_list ()
>>> from /usr/lib/libgnat-3.14p.so.1
>> 
>> Run under the debugger and trace up the stack.
> 
> It is inside of Ada libraries. To check I would need to download the
> Gnat sources and probably recompile these :-(
> 
> Oh, Ada is not so reliable as I cannot find a cause of segfault with
> all checks turned on! :-~ Like C++...
> 
>>> This error appears after exiting my main rountine (well, the main
>>> rountine is not a procedure but a begin...end block of a package
>>> body.)
>> 
>> That's _not_ a main routine; in Ada, the main routine must be a
>> library level procedure. Hmm, can't find that in the LRM, maybe that's
>> a GNAT distinction.
> 
> "Main rountine" was just my informal wording.
> 
>> The sequence of statements in a package body is executed at
>> elaboration time, before the main program's sequence of statements.
> 
> No main procedure at all in my program.

So, have we got this right:

(1) You compiled a package (in effect, a library of routines, NOT a program)
(2) You persuaded the OS to execute its object code
(3) You complain about Ada because it does not execute entirely correctly?

What check do you expect to be able to detect this?
-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: Gnat: system__finalization_implementation__finalize_list

[Wojtek Narczynski]

porton@ex-code.com (Victor Porton) wrote in message news:<3e38664a$0$351$bed64819@news.gradwell.net>...

> It is inside of Ada libraries. To check I would need to download the 
> Gnat sources and probably recompile these :-(

You only need to recompile the runtime libraries. GNAT manual mentions
how to do this.

In default install they are:
/usr/gnat/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/adainclude
/usr/gnat/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/adalib

(But GNAT sources are interesting anyway!)

> Oh, Ada is not so reliable as I cannot find a cause of segfault with 
> all checks turned on! :-~ Like C++...
> 
> >> This error appears after exiting my main rountine (well, the main
> >> rountine is not a procedure but a begin...end block of a package
> >> body.)
> > 

> > That's _not_ a main routine; in Ada, the main routine must be a
> > library level procedure. Hmm, can't find that in the LRM, maybe that's
> > a GNAT distinction.
> 
> "Main rountine" was just my informal wording.

Then you may need to check GNAT manual on invoking Ada from C main
routine. This is not that straightforward. I believe it's described
here http://gcc.gnu.org/onlinedocs/gnat_ug_unx/Generating-the-Binder-Program-in-C.html

Regards,
Wojtek

Re: Gnat: system__finalization_implementation__finalize_list

[Stephen Leake]

porton@ex-code.com (Victor Porton) writes:

> In article <uhebrvixj.fsf@nasa.gov>,
> 	Stephen Leake <Stephen.A.Leake@nasa.gov> writes:
> > porton@ex-code.com (Victor Porton) writes:
> > 
> >> Ideas what this means, how to find the error?
> >> (All checks are turned on!)
> >> 
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x40164c96 in system__finalization_implementation__finalize_list ()
> >> from /usr/lib/libgnat-3.14p.so.1 
> > 
> > Run under the debugger and trace up the stack.
> 
> It is inside of Ada libraries. To check I would need to download the 
> Gnat sources and probably recompile these :-(

That's where the error is _detected_, but not where it is _caused_.
Trace up the stack further untill you get to your code, then you'll
see what caused the error.

-- 
-- Stephe

Re: Gnat: system__finalization_implementation__finalize_list

[Victor Porton]

In article <BA5E221A.1F79%yaldnifw@blueyonder.co.uk>,
	Bill Findlay <yaldnifw@blueyonder.co.uk> writes:
> On 29/1/03 23:35, in article 3e38664a$0$351$bed64819@news.gradwell.net,
> "Victor Porton" <porton@ex-code.com> wrote:
> 
>> In article <uhebrvixj.fsf@nasa.gov>,
>> Stephen Leake <Stephen.A.Leake@nasa.gov> writes:
>>> porton@ex-code.com (Victor Porton) writes:
>>> 
>>>> Ideas what this means, how to find the error?
>>>> (All checks are turned on!)
>>>> 
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> 0x40164c96 in system__finalization_implementation__finalize_list ()
>>>> from /usr/lib/libgnat-3.14p.so.1
>>> 
>>> Run under the debugger and trace up the stack.
>> 
>> It is inside of Ada libraries. To check I would need to download the
>> Gnat sources and probably recompile these :-(
>> 
>> Oh, Ada is not so reliable as I cannot find a cause of segfault with
>> all checks turned on! :-~ Like C++...
>> 
>>>> This error appears after exiting my main rountine (well, the main
>>>> rountine is not a procedure but a begin...end block of a package
>>>> body.)
>>> 
>>> That's _not_ a main routine; in Ada, the main routine must be a
>>> library level procedure. Hmm, can't find that in the LRM, maybe that's
>>> a GNAT distinction.
>> 
>> "Main rountine" was just my informal wording.
>> 
>>> The sequence of statements in a package body is executed at
>>> elaboration time, before the main program's sequence of statements.
>> 
>> No main procedure at all in my program.
> 
> So, have we got this right:
> 
> (1) You compiled a package (in effect, a library of routines, NOT a program)
> (2) You persuaded the OS to execute its object code
> (3) You complain about Ada because it does not execute entirely correctly?
> 
> What check do you expect to be able to detect this?

(1) I compiled my program whose effectively main rountine is not a 
procedure but a begin...end block of a package specifically designed to 
be used as the main rountine. It is perfectly legal accordingly ARM
(however not recommended by the style guide which I not obliged to 
follow).

(2) I executed a properly linked executable with no library level 
procedures. It is legal.

It is Gnat whose manual I have read, and theoretically should work
correctly.

Re: Gnat: system__finalization_implementation__finalize_list

[Stephen Leake]

porton@ex-code.com (Victor Porton) writes:

> (1) I compiled my program whose effectively main rountine is not a 
> procedure but a begin...end block of a package specifically designed to 
> be used as the main rountine. It is perfectly legal accordingly ARM

I could not find the reference that supports this; can you quote it?

> (however not recommended by the style guide which I not obliged to
> follow).
> 
> (2) I executed a properly linked executable with no library level 
> procedures. It is legal.
> 
> It is Gnat whose manual I have read, 

Please give chapter; I didn't think you could do this.

> and theoretically should work correctly.

I don't see how it can arrange to call 'adainit' and 'adafinal' in
this case. That is probably your problem.

Try it with a normal 'main procedure', just for kicks.

-- 
-- Stephe

Re: Gnat: system__finalization_implementation__finalize_list

[Robert A Duff]

Stephen Leake <Stephen.A.Leake@nasa.gov> writes:

> porton@ex-code.com (Victor Porton) writes:
> 
> > (1) I compiled my program whose effectively main rountine is not a 
> > procedure but a begin...end block of a package specifically designed to 
> > be used as the main rountine. It is perfectly legal accordingly ARM
> 
> I could not find the reference that supports this; can you quote it?

Mr. Porton is correct: the main subprogram is optional in Ada 95.
This means that every Ada implementation must support programs
(partitions, actually) that have no main subprogram.

In Ada 83, a main subprogam was required (but it was confusingly called
the "main program").  Since most Ada compilers require the main
subprogram to be a procedure, not a function, I usually call the "main
procedure".

"Main routine" is not Ada jargon -- I suppose Mr. Porton can reasonably
use it to refer to a package body, if he likes.

The reasons for making main subprograms optional in Ada 95 were:
There are some programs that do all their work in library level tasks;
it seems silly to make them write a main subprogram with a "null;"
statement.  Annex E defines the notion of "shared passive partitions",
for which it was thought that main subprograms make no sense.
If you're trying to link some Ada code with some other language, where
the other language gets control first, then it makes no sense to have a
main subprogram on the Ada side.

> I don't see how it can arrange to call 'adainit' and 'adafinal' in
> this case. That is probably your problem.

Adainit is called *before* the main subprogram (if any), and adafinal
*after*.  If there's no main subprogram, that has no effect on when
adainit and adafinal get called.  If it's an all-Ada program, they get
called automatically; if it's a C program with some Ada inside, then the
C code had better call adainit and adafinal "by hand".

> Try it with a normal 'main procedure', just for kicks.

Shouldn't matter.

- Bob

Re: Gnat: system__finalization_implementation__finalize_list

[Alexander Boucke]

>> Try it with a normal 'main procedure', just for kicks.
>
>Shouldn't matter.
>

It doesn't (always) matter...

>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>> 0x40164c96 in system__finalization_implementation__finalize_list ()
>>>>> from /usr/lib/libgnat-3.14p.so.1
>>>>
>(1) I compiled my program whose effectively main rountine is not a
>procedure but a begin...end block of a package specifically designed to
>be used as the main rountine. It is perfectly legal accordingly ARM
>(however not recommended by the style guide which I not obliged to
>follow).
>
>(2) I executed a properly linked executable with no library level
>procedures. It is legal.
>
>It is Gnat whose manual I have read, and theoretically should work
>correctly.

Hi,
I've had exactly the same problem using gnat-3.13p and the Booch Components
(bc-20000219). When using the managed memory pools from the components the
program would not close *after* executing all my code correctly. In the
debugger I've seen this error then... For me the occurence of this error
depends on the size of my lists and can (seemingly) be avoided using
unmanaged storage. And gnat-3.14p, gnat-3.15p and gcc-3.2-gnat do not work
at all for me due to compiler errors :-(

So it might be an Error in the compiler finalization code or probably a
problem with the booch components itself. But I did not find the time to
look more closely yet.

Otherwise I am very pleased with Ada and gnat, looking at a colleague and
his C++ struggles :-)

Regards,
Alexander

Re: Gnat: system__finalization_implementation__finalize_list

[Simon Wright]

"Alexander Boucke" <alexb@lufmech.rwth-aachen.de> writes:

> I've had exactly the same problem using gnat-3.13p and the Booch
> Components (bc-20000219). When using the managed memory pools from
> the components the program would not close *after* executing all my
> code correctly. In the debugger I've seen this error then... For me
> the occurence of this error depends on the size of my lists and can
> (seemingly) be avoided using unmanaged storage. And gnat-3.14p,
> gnat-3.15p and gcc-3.2-gnat do not work at all for me due to
> compiler errors :-(

bc-20000219 is rather old.

There was an error in that release of Managed_Storage (1.7), my log
says

  revision 1.8
  date: 2001/01/28 19:50:25;  author: simon;  state: Exp;  lines: +3 -3
  Deallocations were linked into the first available chunk, not the
  correctly-sized and -aligned one.

which might have some bearing!

Re: Gnat: system__finalization_implementation__finalize_list

[Simon Wright]

porton@ex-code.com (Victor Porton) writes:

> Ideas what this means, how to find the error?
> (All checks are turned on!)
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x40164c96 in system__finalization_implementation__finalize_list () from /usr/lib/libgnat-3.14p.so.1
> 
> This error appears after exiting my main rountine (well, the main 
> rountine is not a procedure but a begin...end block of a package
> body.)

As a matter of interest, do you have any unbounded strings? GNAT has
been known to have occasional wobblies with these in obscure
circumstances. They are controlled, so are involved with finalization,
hence the thought.

Re: Gnat: system__finalization_implementation__finalize_list

[Victor Porton]

In article <x7vn0li2x0w.fsf@smaug.pushface.org>,
	Simon Wright <simon@pushface.org> writes:
> porton@ex-code.com (Victor Porton) writes:
> 
>> Ideas what this means, how to find the error?
>> (All checks are turned on!)
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x40164c96 in system__finalization_implementation__finalize_list () from /usr/lib/libgnat-3.14p.so.1
>> 
>> This error appears after exiting my main rountine (well, the main 
>> rountine is not a procedure but a begin...end block of a package
>> body.)
> 
> As a matter of interest, do you have any unbounded strings? GNAT has
> been known to have occasional wobblies with these in obscure
> circumstances. They are controlled, so are involved with finalization,
> hence the thought.

Seemingly not, by I use somehow similar types (sequences of elements 
representing characters). Well, every character is a controlled object 
and the sequence contains a pointer to it.