From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,590105a5ce7f98b5
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: very long string and Segmentation fault
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: <1152261569.199484.272250@m73g2000cwd.googlegroups.com>
 <2518982.DQdlQZ4ST9@linux1.krischik.com>
 <pan.2006.07.07.19.15.40.699002@linuxchip.demon.co.uk.uk.uk>
Date: Fri, 7 Jul 2006 21:38:34 +0200
Message-ID: <14rcl761v3zf1$.14pu8liretk7v.dlg@40tude.net>
NNTP-Posting-Date: 07 Jul 2006 21:38:18 MEST
NNTP-Posting-Host: 130493f8.newsread2.arcor-online.net
X-Trace: 
 DXC=HN^EFL6VKSXC3N6I?YBjS[Q5U85hF6f;TjW\KbG]kaMXGSi?jHD8GOP8a0<HYEl9JV[6LHn;2LCV^[<mhadbfdU[@C3hO:L:C7Y
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:5559
Date: 2006-07-07T21:38:18+02:00
List-Id: <comp.lang.ada>

On Fri, 07 Jul 2006 19:17:16 GMT, Dr. Adrian Wrigley wrote:

> On Fri, 07 Jul 2006 20:24:52 +0200, Martin Krischik wrote:
> 
>> zychp@o2.pl wrote:
>> 
>>> I have problem with creating very long strings. When I try to create
>>> string bigger than 5MB I get  Segmentation fault.
>> 
>> Well, you should not ;-)  - its certainly a compiler bug.
> 
> Actually, I think it is more of a feature(?)
> 
> I first hit this with GNAT 3.15p (Linux).  I think the explanation
> was that the "new" was allocated on the stack when the data weren't
> being kept after the function returns.  It's called "optimization",
> apparently.  I had to resort to various tricks to get it to use
> heap allocation instead. (making the size non-static might help.
> Calling malloc instead works.)  Very messy.

Hmm, and the pointer wasn't "access all?" I mean, if the pointer were
pool-specific, then GNAT wouldn't have right to do such optimization. Then,
[if that doesn't help] it is quite straightforward to write a storage pool
with Allocate sucking memory from the heap. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de