STORAGE_ERROR in adainit

STORAGE_ERROR in adainit

[James Alan Farrell]

Hello,
I am asking this question again because I think I did not explain it
well before.  (most of the answers boiled down to "make sure you are
calling adainit" -- but adainit is what is giving the error!)

I hope that did not sound snide - I do appreciate that people took the
time to answer.

I have a mixed language program with the main function written in C.
There are several libraries written C and one written in Ada.  The
first command in main is adainit, and that function is raising the
following error:

raised STORAGE_ERROR : stack overflow (or erroneous memory access)

If I remove all the calls to C library routines the call to adainit
does not raise this error.  All the removed calls take place AFTER the
call to adainit -- which makes me think there is something wrong with
how the libraries are linked.  It feels like one library is
overwriting another or something.

I am using gnat version 3.15p to compile the Ada, and gcc 2.8.1 to
compile the C code.

I have looked through the GNAT manual sections on creating libraries
and mixed language programming, and as far as I can tell everything is
correct.  I believe I gave the details in the previous posting.  Due
to the answers to that posting I will simply emphasize that I have
read the relevant sections and unless I am not understanding
something, the makefile is correct.  And again I will emphasize that I
am calling adainit, and that is where the problem is occuring.

Is there anything special I have to do to create C libraries when
linking to Ada libraries?

I've been stuck on this issue for a week and would REALLY like to show
some forward progress.  If anyone has some insight into this problem I
would REALLY appreciate hearing it.

Thank you,
James Alan Farrell
GrammaTech, inc.

Re: STORAGE_ERROR in adainit

[Marc A. Criley]

"James Alan Farrell" <anonymous@anonymous.com> wrote:

> I have a mixed language program with the main function written in C.
> There are several libraries written C and one written in Ada.  The
> first command in main is adainit, and that function is raising the
> following error:
>
> raised STORAGE_ERROR : stack overflow (or erroneous memory access)

Can you write a toy program with a C main that calls into Ada? Like building
one of the example programs. Just to make sure there's no environmental
issue that's causing interference.

Then how about a C main that just calls adainit?

Do you get a storage error on adainit when calling just one of the library
functions? If not, which function triggers the problem and in what library
does it reside?

This is the kind of stuff I'd try to try to starting localizing the
problem...

> Is there anything special I have to do to create C libraries when
> linking to Ada libraries?

No, just plain old compilation of them should work fine.

Re: STORAGE_ERROR in adainit

[James Alan Farrell]

Marc, 
Thanks for the reply

We've already tried the steps you suggest.  The program now is quite
small - simply the call to adainit and to one C library function.  The
complexity (at least at this time) is in building the libraries.  Thus
creating a "toy" program will be little better than creating the
program we have now.

We cannot call any other Ada procedures until Adainit completes
successfully.  A C main that simply calls Adainit works fine.  A C
main that calls Adainit then only functions in the Ada library works
fine.  We only have problems when we start pulling in the C libraries.

We have experimented with calling different C library functions and
found that some cause the problem and others do not, depending on what
C library the function is in.  We  found that none of the libraries
that do *not* call to other libraries show this problem.  Some of
those that do make such calls show the problem and others do not.  I
do not know if one C library calling another C library is relevant.

It is our understanding that when a call is made to a library, that
causes the object file in which the function resides to be linked in.
We traced one occurance of the problem to a call in C library to an
error function that uses fprintf and exit.  Looking at the included
object file (actually the C source), it is a set of error routines,
each of which calls fprintf then exit and nothing else.  So we pulled
the call to the error function out of the library and replaced it with
direct calls to fprintf and exit.  Adainit completed correctly.  So
pulling in the object file that makes calls to these functions and
only these functions causes the problem, but making direct calls to
these functions without pulling in that object file does not.

The file with the error routines are not in the same library as the
function calling them. 

This suggests to me that I need to create a small simple C lib with
one object file in it, then a second simple C lib that calls the
first.  Then a C main that calls Adainit then a function in the second
lib.  I'll report back later today on the results of that experiment.

Don't know if this will make things clearer to anyone else -- their
"as clear as mud" to me.

Thanks again to anyone who can shed further light on this problem.
James

On Wed, 11 Aug 2004 17:29:01 -0500, "Marc A. Criley"
<mcNOSPAM@mckae.com> wrote:

>"James Alan Farrell" <anonymous@anonymous.com> wrote:
>
>> I have a mixed language program with the main function written in C.
>> There are several libraries written C and one written in Ada.  The
>> first command in main is adainit, and that function is raising the
>> following error:
>>
>> raised STORAGE_ERROR : stack overflow (or erroneous memory access)
>
>Can you write a toy program with a C main that calls into Ada? Like building
>one of the example programs. Just to make sure there's no environmental
>issue that's causing interference.
>
>Then how about a C main that just calls adainit?
>
>Do you get a storage error on adainit when calling just one of the library
>functions? If not, which function triggers the problem and in what library
>does it reside?
>
>This is the kind of stuff I'd try to try to starting localizing the
>problem...
>
>> Is there anything special I have to do to create C libraries when
>> linking to Ada libraries?
>
>No, just plain old compilation of them should work fine.
>

Re: STORAGE_ERROR in adainit

[Frode Tenneboe]

James Alan Farrell <anonymous@anonymous.com> wrote:

> This suggests to me that I need to create a small simple C lib with
> one object file in it, then a second simple C lib that calls the
> first.  Then a C main that calls Adainit then a function in the second
> lib.  I'll report back later today on the results of that experiment.

Could you try linking the libraries in a different order? I know X
libraries had/has some issues in which order they were linked on
some platforms. Perhaps this is a similar issue?

 -Frode

PS: Please don't top-post.

-- 
^ Frode Tenneb�               | email: Frode.Tennebo@ericsson.com ^
| Ericsson AS., N-1788 Halden | Phone: +47 67 25 09 39            |
| with Standard.Disclaimer; use Standard.Disclaimer;              |

Re: STORAGE_ERROR in adainit

[James Alan Farrell]

Sorry for my ignorance, what does top-posting mean?

I've tried changing the order that the libraries appear in the gcc -o
command.  Will that change the link order?  (I never make assumptions
like that)  Changing that order did not make a difference.

To follow up on my last post:
I created a small program with an ada library with one procedure that
does a Put_Line("I am in the ada library");  and two C libraries, one
with 

void lib1_func(void)
{
   printf("I am in C library1\n");
}

And the other with 

void lib2_func(void)
{
  printf("I am in C library2, calling C library1\n");
  lib1_func();
}


(each library has one object file with one procedure/function each)

Built everything and linked it all together and it worked fine.

I then replaced the ada library with the one we are developing
(libada_interface.a) and it still worked fine.  Then I replaced the C
libraries with the ones for the production program and I once again
got the error.  Finally I replaced the ada library back to the simple
test library, and I STILL got the error.

Conclusion:  Since the same problem showed up with both ada libraries
and only with the production C libraries, not the test C libraries,
there is something funky with one or more of our production C
libraries.

I have already tried to find any compiler/linker switches that are
different for these libraries than what I would expect but found
nothing.  I will continue to pursue this however.

Thank you,
James Alan Farrell
GrammaTech, inc.




On Thu, 12 Aug 2004 14:20:45 +0000 (UTC), Frode Tenneboe
<ft@alne.edh.ericsson.se> wrote:

>James Alan Farrell <anonymous@anonymous.com> wrote:
>
>> This suggests to me that I need to create a small simple C lib with
>> one object file in it, then a second simple C lib that calls the
>> first.  Then a C main that calls Adainit then a function in the second
>> lib.  I'll report back later today on the results of that experiment.
>
>Could you try linking the libraries in a different order? I know X
>libraries had/has some issues in which order they were linked on
>some platforms. Perhaps this is a similar issue?
>
> -Frode
>
>PS: Please don't top-post.

Re: STORAGE_ERROR in adainit

[James Alan Farrell]

I think I've found the problem:

There was a function in a C library called program_error.  I changed
the name to a_program_error and the storage_error went away.  I
suspect that somewhere hidden in the ada library is a variable called
program error.

Wonder if there are any other names I should avoid using in C
libraries?

(This was on my cut down program.  When I go back to the full program
I suspect there will be other issues to hunt down.  But at least I now
have some idea of what I'm looking for and how to find it!)

Thanks to everyone who sent suggestions!
James

Re: STORAGE_ERROR in adainit

[Ludovic Brenta]

James Alan Farrell writes:
> From: James Alan Farrell Subject: Re: STORAGE_ERROR in adainit
> Newsgroups: comp.lang.ada
> Date: Thu, 12 Aug 2004 15:28:05 -0400
>
> I think I've found the problem:
>
> There was a function in a C library called program_error.  I changed
> the name to a_program_error and the storage_error went away.  I
> suspect that somewhere hidden in the ada library is a variable called
> program error.
>
> Wonder if there are any other names I should avoid using in C
> libraries?

Since this seems to be the problem, here are the names used by GNAT:

(from a-init.c)

/* Addresses of exception data blocks for predefined exceptions. */
extern struct Exception_Data constraint_error;
extern struct Exception_Data numeric_error;
extern struct Exception_Data program_error;
extern struct Exception_Data storage_error;
extern struct Exception_Data tasking_error;
extern struct Exception_Data _abort_signal;

(from s-stalib.ads)

pragma Export (C, Constraint_Error_Def, "constraint_error");
pragma Export (C, Numeric_Error_Def,    "numeric_error");
pragma Export (C, Program_Error_Def,    "program_error");
pragma Export (C, Storage_Error_Def,    "storage_error");
pragma Export (C, Tasking_Error_Def,    "tasking_error");
pragma Export (C, Abort_Signal_Def,     "_abort_signal");

BTW, these are not functions but records.

Also, you will need to look for places where the C version if
program_error was called, and change the name at every call site.

HTH

> (This was on my cut down program.  When I go back to the full program
> I suspect there will be other issues to hunt down.  But at least I now
> have some idea of what I'm looking for and how to find it!)
>
> Thanks to everyone who sent suggestions!
> James

-- 
Ludovic Brenta.

Re: STORAGE_ERROR in adainit

[Björn Persson]

James Alan Farrell wrote:

> I think I've found the problem:
> 
> There was a function in a C library called program_error.  I changed
> the name to a_program_error and the storage_error went away.

It's probably a bug in your compiler that it doesn't detect the name 
clash. GCC-Gnat 3.4 detects it in the following test case:


file clash_test_c.c:

void program_error() {}

void proc() {
    program_error();
}


file clash_test_ada.adb:

procedure Clash_Test_Ada is

    procedure Proc;
    pragma Import (C, Proc, "proc");

begin
    Proc;
end Clash_Test_Ada;


$ gcc -c clash_test_c.c
$ LANG=en_US gnatmake clash_test_ada -largs clash_test_c.o
gnatbind -x clash_test_ada.ali
gnatlink clash_test_ada.ali clash_test_c.o
/home/bjorn/ada/gcc-3.4.0-inst/lib/gcc/i686-pc-linux-gnu/3.4.0/adalib/libgnat.a(s-stalib.o)(.data+0x78):/home/bjorn/ada/gcc-3.4.0-objdir/gcc/ada/rts/s-stalib.adb:104: 
multiple definition of `program_error'
clash_test_c.o(.text+0x0): first defined here
/usr/bin/ld: Warning: size of symbol `program_error' changed from 5 in 
clash_test_c.o to 24 in 
/home/bjorn/ada/gcc-3.4.0-inst/lib/gcc/i686-pc-linux-gnu/3.4.0/adalib/libgnat.a(s-stalib.o)
/usr/bin/ld: Warning: type of symbol `program_error' changed from 2 to 1 
in 
/home/bjorn/ada/gcc-3.4.0-inst/lib/gcc/i686-pc-linux-gnu/3.4.0/adalib/libgnat.a(s-stalib.o)
collect2: ld returned 1 exit status
gnatlink: cannot call /home/bjorn/ada/gcc-3.4.0-inst/bin/gcc
gnatmake: *** link failed.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: STORAGE_ERROR in adainit

[Björn Persson]

James Alan Farrell wrote:

> Sorry for my ignorance, what does top-posting mean?

Quoting (part of) the message you reply to, writing your reply before 
the quoted text instead of after it.

Quoting selected parts of the message you reply to is good for two 
reasons: It shows what exactly you're replying to, and it serves as a 
reminder for me if it's been a while since I read the previous message. 
But if the quote is at the end of your message I have to scroll down to 
see it and then scroll back up to read your reply.


Because it breaks the logical order of conversation.
Why is top-posting bad?


-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: STORAGE_ERROR in adainit

[Stephen Leake]

Ludovic Brenta <ludovic.brenta@insalien.org> writes:

> Since this seems to be the problem, here are the names used by GNAT:
> 
> (from a-init.c)

<snip list of names>

Yuck! These names should at least start with Standard_, and preferably
with GNAT_Standard_.

I would have thought an Ada compiler would know about global name
space polution!

-- 
-- Stephe

Re: STORAGE_ERROR in adainit

[James Alan Farrell]

On Thu, 12 Aug 2004 21:15:01 GMT, Bj�rn Persson
<spam-away@nowhere.nil> wrote:

>James Alan Farrell wrote:
>
>> I think I've found the problem:
>> 
>> There was a function in a C library called program_error.  I changed
>> the name to a_program_error and the storage_error went away.
>
>It's probably a bug in your compiler that it doesn't detect the name 
>clash. GCC-Gnat 3.4 detects it in the following test case:
>
>
>file clash_test_c.c:
>
>void program_error() {}
>
>void proc() {
>    program_error();
>}
>
>
>file clash_test_ada.adb:
>
>procedure Clash_Test_Ada is
>
>    procedure Proc;
>    pragma Import (C, Proc, "proc");
>
>begin
>    Proc;
>end Clash_Test_Ada;
>
>
>$ gcc -c clash_test_c.c
>$ LANG=en_US gnatmake clash_test_ada -largs clash_test_c.o
>gnatbind -x clash_test_ada.ali
>gnatlink clash_test_ada.ali clash_test_c.o
>/home/bjorn/ada/gcc-3.4.0-inst/lib/gcc/i686-pc-linux-gnu/3.4.0/adalib/libgnat.a(s-stalib.o)(.data+0x78):/home/bjorn/ada/gcc-3.4.0-objdir/gcc/ada/rts/s-stalib.adb:104: 
>multiple definition of `program_error'
>clash_test_c.o(.text+0x0): first defined here
>/usr/bin/ld: Warning: size of symbol `program_error' changed from 5 in 
>clash_test_c.o to 24 in 
>/home/bjorn/ada/gcc-3.4.0-inst/lib/gcc/i686-pc-linux-gnu/3.4.0/adalib/libgnat.a(s-stalib.o)
>/usr/bin/ld: Warning: type of symbol `program_error' changed from 2 to 1 
>in 
>/home/bjorn/ada/gcc-3.4.0-inst/lib/gcc/i686-pc-linux-gnu/3.4.0/adalib/libgnat.a(s-stalib.o)
>collect2: ld returned 1 exit status
>gnatlink: cannot call /home/bjorn/ada/gcc-3.4.0-inst/bin/gcc
>gnatmake: *** link failed.


Does it detect the problem if the main in C and Clash_Test_Ada is
exported to C?   That is the problem I am having.  I suspect what you
show here is easier for the compiler to detect than the other way
around.

I found the problem by creating a small test program.  When I did that
I got a linker warning pointing to program_error (indicating in fact
that it is used as data in one place and as a function in another
place).

In the production program I am getting an unrelated linker warning,
but I think for some reason that warning was preventing the warning
that I needed from being displayed.

Thanks to Ludovic for posting that list.  That will be a big help.

Thanks to Stephe for saying that so I don't have too!

James Alan Farrell
GrammaTech, inc.

Re: STORAGE_ERROR in adainit

[Björn Persson]

James Alan Farrell wrote:

> On Thu, 12 Aug 2004 21:15:01 GMT, Björn Persson
> <spam-away@nowhere.nil> wrote:
> 
>>James Alan Farrell wrote:
>>
>>>I think I've found the problem:
>>>
>>>There was a function in a C library called program_error.  I changed
>>>the name to a_program_error and the storage_error went away.
>>
>>It's probably a bug in your compiler that it doesn't detect the name 
>>clash. GCC-Gnat 3.4 detects it in the following test case:
> 
> Does it detect the problem if the main in C and Clash_Test_Ada is
> exported to C?   That is the problem I am having.  I suspect what you
> show here is easier for the compiler to detect than the other way
> around.

Yes, I get the same error messages when the main program is in C:


file clash_test_2_ada.ads:

package Clash_Test_2_Ada is
end Clash_Test_2_Ada;


file clash_test_2_c.c:

void program_error() {}

int main(int argc, char** argv) {
    adainit();
    program_error();
    adafinal();
    return 0;
}


$ gcc -c clash_test_2_c.c
$ gnatmake clash_test_2_ada
gcc -c clash_test_2_ada.ads
$ gnatbind -n clash_test_2_ada.ali
$ LANG=en_US gnatlink clash_test_2_ada.ali clash_test_2_c.o
/home/bjorn/ada/gcc-3.4.0-inst/lib/gcc/i686-pc-linux-gnu/3.4.0/adalib/libgnat.a(s-stalib.o)(.data+0x78):/home/bjorn/ada/gcc-3.4.0-objdir/gcc/ada/rts/s-stalib.adb:104: 
multiple definition of `program_error'
clash_test_2_c.o(.text+0x0): first defined here
/usr/bin/ld: Warning: size of symbol `program_error' changed from 5 in 
clash_test_2_c.o to 24 in 
/home/bjorn/ada/gcc-3.4.0-inst/lib/gcc/i686-pc-linux-gnu/3.4.0/adalib/libgnat.a(s-stalib.o)
/usr/bin/ld: Warning: type of symbol `program_error' changed from 2 to 1 
in 
/home/bjorn/ada/gcc-3.4.0-inst/lib/gcc/i686-pc-linux-gnu/3.4.0/adalib/libgnat.a(s-stalib.o)
collect2: ld returned 1 exit status
gnatlink: cannot call /home/bjorn/ada/gcc-3.4.0-inst/bin/gcc


> I found the problem by creating a small test program.  When I did that
> I got a linker warning pointing to program_error (indicating in fact
> that it is used as data in one place and as a function in another
> place).

So the difference is that you get a warning but an executable is 
produced, while for me, Gnatlink treats the clash as a fatal error and 
refuses to produce an executable.

> In the production program I am getting an unrelated linker warning,
> but I think for some reason that warning was preventing the warning
> that I needed from being displayed.

While I don't know what that warning is about, I'd recommend that you 
fix it. It may well be another fatal error.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: STORAGE_ERROR in adainit

[James Alan Farrell]

On Tue, 17 Aug 2004 21:37:11 GMT, Bj�rn Persson
<spam-away@nowhere.nil> wrote:


>Yes, I get the same error messages when the main program is in C:
>
>
>file clash_test_2_ada.ads:
>
>package Clash_Test_2_Ada is
>end Clash_Test_2_Ada;
>
>
>file clash_test_2_c.c:
>
>void program_error() {}
>
>int main(int argc, char** argv) {
>    adainit();
>    program_error();
>    adafinal();
>    return 0;
>}
>
>
>$ gcc -c clash_test_2_c.c
>$ gnatmake clash_test_2_ada
>gcc -c clash_test_2_ada.ads
>$ gnatbind -n clash_test_2_ada.ali
>$ LANG=en_US gnatlink clash_test_2_ada.ali clash_test_2_c.o
>/home/bjorn/ada/gcc-3.4.0-inst/lib/gcc/i686-pc-linux-gnu/3.4.0/adalib/libgnat.a(s-stalib.o)(.data+0x78):/home/bjorn/ada/gcc-3.4.0-objdir/gcc/ada/rts/s-stalib.adb:104: 
>multiple definition of `program_error'
>clash_test_2_c.o(.text+0x0): first defined here
>/usr/bin/ld: Warning: size of symbol `program_error' changed from 5 in 
>clash_test_2_c.o to 24 in 
>/home/bjorn/ada/gcc-3.4.0-inst/lib/gcc/i686-pc-linux-gnu/3.4.0/adalib/libgnat.a(s-stalib.o)
>/usr/bin/ld: Warning: type of symbol `program_error' changed from 2 to 1 
>in 
>/home/bjorn/ada/gcc-3.4.0-inst/lib/gcc/i686-pc-linux-gnu/3.4.0/adalib/libgnat.a(s-stalib.o)
>collect2: ld returned 1 exit status
>gnatlink: cannot call /home/bjorn/ada/gcc-3.4.0-inst/bin/gcc
>
>

I'll play around with this when I get a chance.


>> I found the problem by creating a small test program.  When I did that
>> I got a linker warning pointing to program_error (indicating in fact
>> that it is used as data in one place and as a function in another
>> place).
>
>So the difference is that you get a warning but an executable is 
>produced, while for me, Gnatlink treats the clash as a fatal error and 
>refuses to produce an executable.
>

Perhaps you have a newer version of gnatlink?  It seems to me we've
upgraded a month or so ago, but perhaps that upgrade was only some
libraries (we're using asis, and we may have only upgraded the asis
libs instead of the compiler).

Other than that I don't understand why you would have different
results.  Perhaps it is because my program_error C function is in a
library, not in a .o file?  Don't know what different that would make,
though.  I'll play around with the above program to see what I get.

>> In the production program I am getting an unrelated linker warning,
>> but I think for some reason that warning was preventing the warning
>> that I needed from being displayed.
>
>While I don't know what that warning is about, I'd recommend that you 
>fix it. It may well be another fatal error.

*sigh* in a perfect world...

Thanks again,
James Alan Farrell

Re: STORAGE_ERROR in adainit

[Björn Persson]

James Alan Farrell wrote:

> Perhaps you have a newer version of gnatlink?  It seems to me we've
> upgraded a month or so ago, but perhaps that upgrade was only some
> libraries (we're using asis, and we may have only upgraded the asis
> libs instead of the compiler).

Yes. You said you use Gnat 3.15. I use the Gnat that is part of GCC 
3.4.0, which is newer (although the version numbers might seem to 
indicate otherwise), and naturally has some improvements. Unfortunately 
it lacks Asis and several other surrounding tools.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: STORAGE_ERROR in adainit

[Simon Wright]

James Alan Farrell <anonymous@anonymous.com> writes:

> Other than that I don't understand why you would have different
> results.  Perhaps it is because my program_error C function is in a
> library, not in a .o file?  Don't know what different that would make,
> though.  I'll play around with the above program to see what I get.

Symbols in a library.a are loaded if required (ie, if something before
-l rary requires symbol foo, and module bar.o in library.a contains a
definition of foo, then bar.o is "extracted" from library.a and linked
in).

If on the other hand you include bar.o on the ld command line, it's
linked unconditionally.

-- 
Simon Wright                               100% Ada, no bugs.

Re: STORAGE_ERROR in adainit

[James Alan Farrell]

On 18 Aug 2004 20:44:30 +0100, Simon Wright <simon@pushface.org>
wrote:

>James Alan Farrell <anonymous@anonymous.com> writes:
>
>> Other than that I don't understand why you would have different
>> results.  Perhaps it is because my program_error C function is in a
>> library, not in a .o file?  Don't know what different that would make,
>> though.  I'll play around with the above program to see what I get.
>
>Symbols in a library.a are loaded if required (ie, if something before
>-l rary requires symbol foo, and module bar.o in library.a contains a
>definition of foo, then bar.o is "extracted" from library.a and linked
>in).
>
>If on the other hand you include bar.o on the ld command line, it's
>linked unconditionally.

So what you are saying is (at least in this situation) it should make
no difference because the whole of the .o file is linked(?)  This
agrees with my understanding, but not with what we are seeing.  Either
I should not get the problem because the object file with
program_error is not linked OR I should get the same warning Bjorn
got.

(Apologies for the spelling of Bjorn - I do not know how to access
non-English characters on the keyboard)

Unfortunately I have not had time to look at Bjorn's program today,
and don't know if I'll get to it this week, but I will as soon as I
can.

James Alan