* storage size pragmas @ 2000-05-07 0:00 ANTHONY GAIR 2000-05-07 0:00 ` Keith Thompson ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: ANTHONY GAIR @ 2000-05-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-07 0:00 storage size pragmas ANTHONY GAIR @ 2000-05-07 0:00 ` Keith Thompson 2000-05-07 0:00 ` Ted Dennison 2000-05-07 0:00 ` Pascal Obry 2 siblings, 0 replies; 22+ messages in thread From: Keith Thompson @ 2000-05-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-07 0:00 storage size pragmas ANTHONY GAIR 2000-05-07 0:00 ` Keith Thompson @ 2000-05-07 0:00 ` Ted Dennison 2000-05-07 0:00 ` ANTHONY GAIR ` (3 more replies) 2000-05-07 0:00 ` Pascal Obry 2 siblings, 4 replies; 22+ messages in thread From: Ted Dennison @ 2000-05-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-07 0:00 ` Ted Dennison @ 2000-05-07 0:00 ` ANTHONY GAIR 2000-05-07 0:00 ` Robert Dewar ` (2 more replies) 2000-05-07 0:00 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 3 replies; 22+ messages in thread From: ANTHONY GAIR @ 2000-05-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-07 0:00 ` ANTHONY GAIR @ 2000-05-07 0:00 ` Robert Dewar 2000-05-09 0:00 ` ANTHONY GAIR 2000-05-07 0:00 ` Robert Dewar 2000-05-08 0:00 ` Ted Dennison 2 siblings, 1 reply; 22+ messages in thread From: Robert Dewar @ 2000-05-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-07 0:00 ` Robert Dewar @ 2000-05-09 0:00 ` ANTHONY GAIR 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Robert A Duff 0 siblings, 2 replies; 22+ messages in thread From: ANTHONY GAIR @ 2000-05-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-09 0:00 ` ANTHONY GAIR @ 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Robert A Duff 1 sibling, 0 replies; 22+ messages in thread From: Robert Dewar @ 2000-05-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-09 0:00 ` ANTHONY GAIR 2000-05-09 0:00 ` Robert Dewar @ 2000-05-09 0:00 ` Robert A Duff 2000-05-09 0:00 ` Robert Dewar 1 sibling, 1 reply; 22+ messages in thread From: Robert A Duff @ 2000-05-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-09 0:00 ` Robert A Duff @ 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Robert A Duff ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Robert Dewar @ 2000-05-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-09 0:00 ` Robert Dewar @ 2000-05-09 0:00 ` Robert A Duff 2000-05-10 0:00 ` Laurent Guerby 2000-05-09 0:00 ` Ted Dennison 2000-05-09 0:00 ` Larry Kilgallen 2 siblings, 1 reply; 22+ messages in thread From: Robert A Duff @ 2000-05-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-09 0:00 ` Robert A Duff @ 2000-05-10 0:00 ` Laurent Guerby 0 siblings, 0 replies; 22+ messages in thread From: Laurent Guerby @ 2000-05-10 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Robert A Duff @ 2000-05-09 0:00 ` Ted Dennison 2000-05-09 0:00 ` Larry Kilgallen 2 siblings, 0 replies; 22+ messages in thread From: Ted Dennison @ 2000-05-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Robert A Duff 2000-05-09 0:00 ` Ted Dennison @ 2000-05-09 0:00 ` Larry Kilgallen 2 siblings, 0 replies; 22+ messages in thread From: Larry Kilgallen @ 2000-05-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-07 0:00 ` ANTHONY GAIR 2000-05-07 0:00 ` Robert Dewar @ 2000-05-07 0:00 ` Robert Dewar 2000-05-08 0:00 ` Ted Dennison 2 siblings, 0 replies; 22+ messages in thread From: Robert Dewar @ 2000-05-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-07 0:00 ` ANTHONY GAIR 2000-05-07 0:00 ` Robert Dewar 2000-05-07 0:00 ` Robert Dewar @ 2000-05-08 0:00 ` Ted Dennison 2000-05-08 0:00 ` Robert Dewar 2 siblings, 1 reply; 22+ messages in thread From: Ted Dennison @ 2000-05-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-08 0:00 ` Ted Dennison @ 2000-05-08 0:00 ` Robert Dewar 2000-05-08 0:00 ` Ted Dennison 0 siblings, 1 reply; 22+ messages in thread From: Robert Dewar @ 2000-05-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-08 0:00 ` Robert Dewar @ 2000-05-08 0:00 ` Ted Dennison 2000-05-08 0:00 ` Robert Dewar 0 siblings, 1 reply; 22+ messages in thread From: Ted Dennison @ 2000-05-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-08 0:00 ` Ted Dennison @ 2000-05-08 0:00 ` Robert Dewar 0 siblings, 0 replies; 22+ messages in thread From: Robert Dewar @ 2000-05-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-07 0:00 ` Ted Dennison 2000-05-07 0:00 ` ANTHONY GAIR @ 2000-05-07 0:00 ` Robert Dewar 2000-05-07 0:00 ` Robert Dewar 2000-05-07 0:00 ` Robert Dewar 3 siblings, 0 replies; 22+ messages in thread From: Robert Dewar @ 2000-05-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-07 0:00 ` Ted Dennison 2000-05-07 0:00 ` ANTHONY GAIR 2000-05-07 0:00 ` Robert Dewar @ 2000-05-07 0:00 ` Robert Dewar 2000-05-07 0:00 ` Robert Dewar 3 siblings, 0 replies; 22+ messages in thread From: Robert Dewar @ 2000-05-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-07 0:00 ` Ted Dennison ` (2 preceding siblings ...) 2000-05-07 0:00 ` Robert Dewar @ 2000-05-07 0:00 ` Robert Dewar 3 siblings, 0 replies; 22+ messages in thread From: Robert Dewar @ 2000-05-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: storage size pragmas 2000-05-07 0:00 storage size pragmas ANTHONY GAIR 2000-05-07 0:00 ` Keith Thompson 2000-05-07 0:00 ` Ted Dennison @ 2000-05-07 0:00 ` Pascal Obry 2 siblings, 0 replies; 22+ messages in thread From: Pascal Obry @ 2000-05-07 0:00 UTC (permalink / raw) [-- 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" ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2000-05-10 0:00 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-05-07 0:00 storage size pragmas ANTHONY GAIR 2000-05-07 0:00 ` Keith Thompson 2000-05-07 0:00 ` Ted Dennison 2000-05-07 0:00 ` ANTHONY GAIR 2000-05-07 0:00 ` Robert Dewar 2000-05-09 0:00 ` ANTHONY GAIR 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Robert A Duff 2000-05-09 0:00 ` Robert Dewar 2000-05-09 0:00 ` Robert A Duff 2000-05-10 0:00 ` Laurent Guerby 2000-05-09 0:00 ` Ted Dennison 2000-05-09 0:00 ` Larry Kilgallen 2000-05-07 0:00 ` Robert Dewar 2000-05-08 0:00 ` Ted Dennison 2000-05-08 0:00 ` Robert Dewar 2000-05-08 0:00 ` Ted Dennison 2000-05-08 0:00 ` Robert Dewar 2000-05-07 0:00 ` Robert Dewar 2000-05-07 0:00 ` Robert Dewar 2000-05-07 0:00 ` Robert Dewar 2000-05-07 0:00 ` Pascal Obry
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox