storage size pragmas

storage size pragmas

[ANTHONY GAIR]

For those of you watching my progress with Ada tasks and segmentation faults
with both bated breath and intrepidation for the next exciting installment.

Would a large array stored inside a task cause a segmentation fault if no
storage size pragma is used ?

the storage size is roughly 10000 * (8 + 8+ 8+ 8+8) array,

answers on a postcard please ....
Are ADA and linux a good combination :-
www.remotely.useful.com

Re: storage size pragmas

[Keith Thompson]

anthonygair@aol.comremoveme (ANTHONY GAIR) writes:
> For those of you watching my progress with Ada tasks and segmentation faults
> with both bated breath and intrepidation for the next exciting installment.
> 
> Would a large array stored inside a task cause a segmentation fault if no
> storage size pragma is used ?
> 
> the storage size is roughly 10000 * (8 + 8+ 8+ 8+8) array,

If the large array can't be allocated, it *should* cause a
Storage_Error exception (if you're compiling with all checks on).
The exception may not be visible if it occurs within a task.

Add a Storage_Size pragma and see what happens.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: storage size pragmas

[Ted Dennison]

ANTHONY GAIR wrote:

> For those of you watching my progress with Ada tasks and segmentation faults
> with both bated breath and intrepidation for the next exciting installment.
>
> Would a large array stored inside a task cause a segmentation fault if no
> storage size pragma is used ?

Well, my first guess when I see the words "exception" and "task" together is
typically that the user made some big honking object in his task that blew out
the default stack size for tasks. However, since that usually causes
Storage_Error rather than a seg fault, I figured that probably wasn't it, and
didn't say anything about it.

Try jacking up the task's stack to ridiculous levels with "for
Taskname'Storage_Size use" or a "pragma Storage_Size". If that fixes it, send a
bug report to your vendor. I believe the condition of running out of stack space
should cause Storage_Error, not a seg fault.

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: storage size pragmas

[Robert Dewar]

In article <3915BC28.A0D56A68@telepath.com>,
  Ted Dennison <dennison@telepath.com> wrote:

> Try jacking up the task's stack to ridiculous levels with "for
> Taskname'Storage_Size use" or a "pragma Storage_Size". If that
fixes it, send a
> bug report to your vendor. I believe the condition of running
out of stack space
> should cause Storage_Error, not a seg fault.

Also be careful that even if a storage error fault is signalled
in a task, the usual effect is to make the task terminate
silently, which can have pretty horrible effects on your
program.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: storage size pragmas

[ANTHONY GAIR]

The witch is dead.... it was a storage_error.. no exception was produced in
fact my ada installation does not think it important to tell me about any
details such as errors. sorry for wasting everyones time but ......as it turns
out segmentation faults can be caused by bad prXXX er ... not placing storage
pragmas in big chogablog largist tasks.


Are ADA and linux a good combination :-
www.remotely.useful.com

Re: storage size pragmas

[Robert Dewar]

In article <20000507181719.23279.00001715@ng-fc1.aol.com>,
  anthonygair@aol.comremoveme (ANTHONY GAIR) wrote:
>
> The witch is dead.... it was a storage_error

Note also that it is often good practice to allocate really
large arrays on the heap, since you don't want to have to have
giant task stacks for every task in most environments.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: storage size pragmas

[ANTHONY GAIR]

I am a newby on the linux scene, and a previous vax vms programmer. Can you
explain?

Are ADA and linux a good combination :-
www.remotely.useful.com

Re: storage size pragmas

[Robert A Duff]

anthonygair@aol.comremoveme (ANTHONY GAIR) writes:

> I am a newby on the linux scene, and a previous vax vms programmer. Can you
> explain?
> 
> Are ADA and linux a good combination :-
> www.remotely.useful.com

You didn't quote any context, so probably nobody has the slightest idea
what you're talking about.  Explain *what*?!

- Bob

Re: storage size pragmas

[Robert Dewar]

In article <wcc66sn22rp.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> anthonygair@aol.comremoveme (ANTHONY GAIR) writes:
>
> You didn't quote any context, so probably nobody has the
> slightest idea what you're talking about.  Explain *what*?!


Actually it's not quite that simple, and in fact I find this
is a cause of lots of confusion. There are two kinds of ways
of reading news.

If you follow threads, with an appropriate reader, you know
EXACTLY which message is replying to which (you get a full
tree structure).

But lots of people read news in a strictly sequential manner,
and if you don't give enough context in messages, then they
get completely lost.

Please note that giving enough context in messages means what
it says, one of the MOST annoying behaviors on usenet is to
quote giant articles in their entirety, and then at the end
add some meaningless statement like "me too", or "right on!"

Quote just enough context to remind people what you are talking
about. I also noticed the lack of context in this message, but
was using a thread following news reader (deja classic with
=dnc set) so I could tell the question was about using
allocators with large arrays.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: storage size pragmas

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> If you follow threads, with an appropriate reader, you know
> EXACTLY which message is replying to which (you get a full
> tree structure).

I use "M-x gnus", in Emacs, which (claims to) follow threads.  But once
I've read an article, it disappears, unless I do something special.  I
get a tree structure, but it's restricted to those I have not yet read.
And even then, I can't follow the structure of a giant tree entirely in
my head.

Probably there's some Emacs keystroke to say, "Show me the article this
one is replying to", but I'm too lazy to know how to do that.

- Bob

Re: storage size pragmas

[Laurent Guerby]

Robert A Duff <bobduff@world.std.com> writes:
> Probably there's some Emacs keystroke to say, "Show me the article this
> one is replying to", but I'm too lazy to know how to do that.

In summary: ^
In message: C-c ^

C-h m rulez ;-).

-- 
Laurent Guerby <guerby@acm.org>

Re: storage size pragmas

[Larry Kilgallen]

In article <8f9be7$al9$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:
> In article <wcc66sn22rp.fsf@world.std.com>,
>   Robert A Duff <bobduff@world.std.com> wrote:
>> anthonygair@aol.comremoveme (ANTHONY GAIR) writes:
>>
>> You didn't quote any context, so probably nobody has the
>> slightest idea what you're talking about.  Explain *what*?!

> If you follow threads, with an appropriate reader, you know
> EXACTLY which message is replying to which (you get a full
> tree structure).

I read by thread, but starting with the first message I have not
yet read.  If that message gives no context, clearly the author
is contented just to see himself in print.

> Please note that giving enough context in messages means what
> it says, one of the MOST annoying behaviors on usenet is to
> quote giant articles in their entirety, and then at the end
> add some meaningless statement like "me too", or "right on!"

Certainly.  My hard-and-fast rule is to ignore posts that do
not get around to adding anything new in the first screenful.

Re: storage size pragmas

[Ted Dennison]

In article <8f9be7$al9$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <wcc66sn22rp.fsf@world.std.com>,
>   Robert A Duff <bobduff@world.std.com> wrote:
> > You didn't quote any context, so probably nobody has the
> > slightest idea what you're talking about.  Explain *what*?!
>
> If you follow threads, with an appropriate reader, you know
> EXACTLY which message is replying to which (you get a full
> tree structure).

Well, that's always true for us Deja readers. But for folks using normal
newsreaders, old and/or read messages tend to get removed after the
session is complete (even for "threaded" readers). The unquoted message
in question was pretty recent though, so that might not have been the
issue here.

But that brings us to another issue: if someone is replying to a recent
message, its quite possible that a lot of readers will get the reply
before they get the message it replies to.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: storage size pragmas

[Robert Dewar]

In article <20000509091700.21257.00002190@ng-ff1.aol.com>,
  anthonygair@aol.comremoveme (ANTHONY GAIR) wrote:
>
> I am a newby on the linux scene, and a previous vax vms
programmer. Can you
> explain?


Look up allocators and the use of the NEW keyword in your
Ada reference material. You will also need to understand
the use of access types.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: storage size pragmas

[Robert Dewar]

In article <20000507181719.23279.00001715@ng-fc1.aol.com>,
  anthonygair@aol.comremoveme (ANTHONY GAIR) wrote:
>
> The witch is dead.... it was a storage_error.. no exception
was produced in
> fact my ada installation does not think it important to tell
me about any
> details such as errors. sorry for wasting everyones time but
......as it turns
> out segmentation faults can be caused by bad prXXX er ... not
placing storage
> pragmas in big chogablog largist tasks.

Well if you don't enable stack checking (you need -fstack-check
in gcc to do this), then you won't get stack checking. It is
as simple as that. I assume you have indeed read the GNAT users
guide, but to be fair, this is something you have to go to the
GCC documentation for. In the latest version of the GNAT
documentation, we have copied a section on stack checking.
We choose to have stack checking off by default, because it
is a gcc option, and our convention in GNAT is to set the
defaults for gcc options the same way as all other GCC
compilers, or it causes a lot of confusion.

This sort of GNAT specific detail is better discussed on
chat@gnat.com rather than comp.lang.ada.

Note incidentally that even if you DO enable stack checking,
your implementation still will not tell you about this error,
since the required Ada semantics for tasking is to silently
terminate a task on an unhandled exception. You may want to
put an exception handler at the outer level of every task
to avoid this surprise.

(I dislike this design in Ada, I would prefer that an unhandled
exception in ANY task cause implementation defined program
termination, as it does in the environment task. I think this
would be FAR more useful. If you really want the undesirable
semantics required now, you could get them with a handler
at the outer level of a task that said

   when others => null;

Yes, that's a highly suspicious handler, and that's the point!!!







>
> Are ADA and linux a good combination :-
> www.remotely.useful.com
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: storage size pragmas

[Ted Dennison]

In article <20000507181719.23279.00001715@ng-fc1.aol.com>,
  anthonygair@aol.comremoveme (ANTHONY GAIR) wrote:
>
> The witch is dead.... it was a storage_error.. no exception was
> produced in fact my ada installation does not think it important to
> tell me about any details such as errors. sorry for wasting everyones
> time but ......as it turns out segmentation faults can be caused by
> bad prXXX er ... not placing storage pragmas in big chogablog largist
> tasks.

I'm sorry if I may have misled you a bit here. One of the things that I
forgot is that Gnat (unlike most Ada compilers) does not default to full
checking. Certian checks that are deemed by the compiler writers to be
more expensive than they are worth are turned off by default, even if
that means it technicly isn't following the Ada standard. (Of course the
standard also allows modes where the checks are turned off).

I'm not ragging on the Gnat folks for choosing to do this. Its just not
the typical choice that other compiler vendors have made, so I had
forgotten that ACT did this.

Also Robert Dewar is correct in pointing out that if the check was in
there, your task would just have died silently instead. *Another* thing
I forgot is that I always put a last-ditch handler in my task bodies to
print out information about task-terminating exceptions. The general
form is the following:

   exception
      when Error : others =>
         -- Try to put one last-ditch message to the screen saying
         -- that the {taskname} died
         Ada.Text_Io.Put_Line
            ("{taskname} died with the following exception:" &
             Ada.Characters.Latin_1.Cr & Ada.Characters.Latin_1.Lf &
             Ada.Exceptions.Exception_Information (Error));

If you don't do this, then typically your indication that a task has
died is that other tasks get Program_Error when attempting to rendezvous
with them. That doesn't exactly make for easy debugging.


--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: storage size pragmas

[Robert Dewar]

In article <8f6kko$944$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
In article <8f6kko$944$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:

> I'm sorry if I may have misled you a bit here. One of the
things that I
> forgot is that Gnat (unlike most Ada compilers) does not
default to full
> checking.

True.

> Certian checks that are deemed by the compiler writers to be
> more expensive than they are worth are turned off by default

False (Ted, you don't know GNAT that well, so be careful about
claims like this :-)

There are many reasons why we choose to have certain modes
as the default, the one you gave above is NOT the most
common case at all. Other examples are:

  a) The RM provides for run-time checking of elaboration rules,
  leading to implementation dependent elaboration mode chaos
that
  often causes huge problems in porting programs. GNAT by
default
  checks elaboration at compile time using a static approach
that
  is more efficient, and much safer. The choice here is not
because
  of the expense of the check, but because we consider
  the static mode to be far preferable in every respect.

  b) Stack checking is off by default in all GCC compilers. We
  find it less confusing to have GNAT use the same defaults as
  other GCC compilers, rather than having the default options
  be language specific.

  c) The default compiler is determined by the extension, so if
  you want to ensure compilation in Ada rather than another
  language when you have a non-default file name, you must
  use the -x ada switch.

  d) We like to keep options consistent from one version of the
  compiler to another. So although at this stage -gnato is
  typically not a very expensive checking option, and could
  well be turned on by default, we prefer to keep
  the default the way it has been in the

> even if that means it technicly isn't following the Ada
standard.

Nope, that's completely inaccurate. The standard has nothing to
say
about default options, and neither do the validation tests. All
either
requires is that you provide an Ada compiler that conforms to
the
Ada standard. It says nothing about the commands for running the
compiler. Generally you need to look at the compiler
documentation
to see what set of options is required (this set of options will
also be documented in the validation VSR). So it is quite wrong
to say that GNAT is technically not following the Ada standard.
It
is right to say that a user not using the appropriate options
and
expecting to get accurate Ada semantics may be misusing the
compiler
(a common mistake among those allergic to reading
documentatation :-)

> Of course the standard also allows modes where the checks are
turned off).

Well, only as a special case that it allows an Ada compiler to
do absolutely
anything it likes under control of appropriate pragmas or
compilation
switches :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: storage size pragmas

[Ted Dennison]

In article <8f754a$t03$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:

> In article <8f6kko$944$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:
>
> > Certian checks that are deemed by the compiler writers to be
> > more expensive than they are worth are turned off by default
>
> False (Ted, you don't know GNAT that well, so be careful about
> claims like this :-)
>
> There are many reasons why we choose to have certain modes
> as the default, the one you gave above is NOT the most
...

That's right. You have discussed all that here before. Blame my faulty
memory again. Perhaps I should start eating more beets or something.
:-)

> > even if that means it technicly isn't following the Ada
> standard.
>
> Nope, that's completely inaccurate. The standard has nothing to
> say
> about default options, and neither do the validation tests. All

Well, that was a simplification which I suppose was bound to draw ire.
What I was trying to get at is that if you just use the default flags,
you do *not* get a standard Ada compilation.

That's a bit odd in the Ada world as far as I can tell. But that kind of
thing is quite common in the C and C++ world, so I guess it shouldn't
really suprise anyone.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: storage size pragmas

[Robert Dewar]

In article <8f76u1$vac$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> That's a bit odd in the Ada world as far as I can tell.

Right. That's fair, and perhaps if we were building a stand
alone Ada
technology, we might make different choices, although I
really think the choice of static elaboration as the default
is very valuable. This means that people who do NOT bother
to investigate the issue end up doing the right thing :-)



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: storage size pragmas

[Robert Dewar]

In article <3915BC28.A0D56A68@telepath.com>,
  Ted Dennison <dennison@telepath.com> wrote:

> Try jacking up the task's stack to ridiculous levels with "for
> Taskname'Storage_Size use" or a "pragma Storage_Size". If that
fixes it, send a
> bug report to your vendor. I believe the condition of running
out of stack space
> should cause Storage_Error, not a seg fault.

Depends on whether you have enabled stack checking. As always
be sure to read the documentation! In this case for older
versions of GNAT, you need to read the GCC documentation as
well as the GNAT documentation.

Also, I recommend that you consider using the chat@gnat.com
list for specific questions about GNAT ...




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: storage size pragmas

[Robert Dewar]

In article <3915BC28.A0D56A68@telepath.com>,
  Ted Dennison <dennison@telepath.com> wrote:

> Try jacking up the task's stack to ridiculous levels with "for
> Taskname'Storage_Size use" or a "pragma Storage_Size". If that
fixes it, send a
> bug report to your vendor. I believe the condition of running
out of stack space
> should cause Storage_Error, not a seg fault.

Depends on whether you have enabled stack checking. As always
be sure to read the documentation! In this case for older
versions of GNAT, you need to read the GCC documentation as
well as the GNAT documentation.

Also, I recommend that you consider using the chat@gnat.com
list for specific questions about GNAT ...


> --
> T.E.D.
>
> Home - mailto:dennison@telepath.com  Work -
mailto:dennison@ssd.fsi.com
> WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  -
10545591
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: storage size pragmas

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]


ANTHONY GAIR a �crit dans le message
<20000507094954.10742.00001811@ng-bj1.aol.com>...
>
>For those of you watching my progress with Ada tasks and segmentation
faults
>with both bated breath and intrepidation for the next exciting installment.
>
>Would a large array stored inside a task cause a segmentation fault if no
>storage size pragma is used ?
>
>the storage size is roughly 10000 * (8 + 8+ 8+ 8+8) array,
>


Yes it could be the problem.

Pascal.


--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"