function "&" for strings type cause memory problem.

function "&" for strings type cause memory problem.

[bubble]

dear all:
I have a project need mix 2 language (VB and Ada).


VB do GUI  and monitor the real time quote then trigger kernel work.
Ada with gnatcom to do kernel work (financial model pricing).

in the project, a code snip will raise storage_error excpeiton because I 
combine 2  BIG string to 1 string.

I test the code snip and I get some problem in the statement, Nstring2 := 
new String'(String1 & String2) .

if I compiling the code to stand alone execute file and enable pragma 
Linker_Options ("-Wl,--stack=0x10000000");
It both  passed.
if I compiling it to DLL ,it pass test 1 and fail in test2

                                                    Test 1              | 
Test 2
-----------------------------------------------------------------------------------------------
.exe with Linker_Options       |     Pass 
Pass
.exe without Liner_Options    |     Pass                                Fail
.dll with Linker_Options         |    Pass 
Fail
.dll without Linker_Options    |    Pass 
Fail

Test Environment
----------------------------------------------------------------------------------------------
OS:Windows XP.
memory :640 MB.
VB: Microsoft Visual Basic 6
gnatcom version: 1.4
ada compiler: Gnat GPL 2005



I guess functin "&" for string type may have potential  problem in gnat 
windows editions.
does any body know the problem and give me some suggestion.
thanks








Test Code
--------------------------------------------------------------------------------------------------
with Ada.Text_IO;
Use Ada.Text_Io;

procedure test is
   --pragma Linker_Options ("-Wl,--stack=0x10000000");
   type access_string is access all String;
   String1 : String := (1 .. 10_000_000 => 'a');
   String2 : String := (1 .. 10_000_000 => 'b');

begin
   declare
      nString : access_string := null;
   begin
      nString:= new String (1 .. String1'Length + String2'Length);
      nString.all (String1'First .. String2'Last) := String1;
      nString.all ( String1'First + String2'First.. String1'First + 
String2'Last):= String2;
      Put_Line("Test 1 Passed");
   Exception
      When Others=>
         Put_Line("Test 1 Fail");
   end;
   declare
      Nstring2 : access_string := null;
   begin
      Nstring2 := new String'(String1 & String2);
      Put_Line("Test 2 Passed ");
   exception
      when others =>
         Ada.Text_IO.Put_Line ("Test 2 Fail");
   end;
end test; 

Re: function "&" for strings type cause memory problem.

[Alex R. Mosteo]

bubble wrote:
> dear all:
> I have a project need mix 2 language (VB and Ada).
> 
> 
> VB do GUI  and monitor the real time quote then trigger kernel work.
> Ada with gnatcom to do kernel work (financial model pricing).
> 
> in the project, a code snip will raise storage_error excpeiton because I 
> combine 2  BIG string to 1 string.
> 
> I test the code snip and I get some problem in the statement, Nstring2 := 
> new String'(String1 & String2) .
> 
> if I compiling the code to stand alone execute file and enable pragma 
> Linker_Options ("-Wl,--stack=0x10000000");
> It both  passed.
> if I compiling it to DLL ,it pass test 1 and fail in test2
> 
>                                                     Test 1              | 
> Test 2
> -----------------------------------------------------------------------------------------------
> .exe with Linker_Options       |     Pass 
> Pass
> .exe without Liner_Options    |     Pass                                Fail
> .dll with Linker_Options         |    Pass 
> Fail
> .dll without Linker_Options    |    Pass 
> Fail
> 
> Test Environment
> ----------------------------------------------------------------------------------------------
> OS:Windows XP.
> memory :640 MB.
> VB: Microsoft Visual Basic 6
> gnatcom version: 1.4
> ada compiler: Gnat GPL 2005
> 
> 
> 
> I guess functin "&" for string type may have potential  problem in gnat 
> windows editions.
> does any body know the problem and give me some suggestion.
> thanks

This is just stack exhaustion. You can try either configuring your stack 
size big enough for any string in your system, or using Unbounded_String 
which uses memory from the heap. Though if you end converting them to 
regular String at some point I reckon you may have the same problem.


> Test Code
> --------------------------------------------------------------------------------------------------
> with Ada.Text_IO;
> Use Ada.Text_Io;
> 
> procedure test is
>    --pragma Linker_Options ("-Wl,--stack=0x10000000");
>    type access_string is access all String;
>    String1 : String := (1 .. 10_000_000 => 'a');
>    String2 : String := (1 .. 10_000_000 => 'b');
> 
> begin
>    declare
>       nString : access_string := null;
>    begin
>       nString:= new String (1 .. String1'Length + String2'Length);
>       nString.all (String1'First .. String2'Last) := String1;
>       nString.all ( String1'First + String2'First.. String1'First + 
> String2'Last):= String2;
>       Put_Line("Test 1 Passed");
>    Exception
>       When Others=>
>          Put_Line("Test 1 Fail");
>    end;
>    declare
>       Nstring2 : access_string := null;
>    begin
>       Nstring2 := new String'(String1 & String2);
>       Put_Line("Test 2 Passed ");
>    exception
>       when others =>
>          Ada.Text_IO.Put_Line ("Test 2 Fail");
>    end;
> end test; 
> 
> 

Re: function "&" for strings type cause memory problem.

[Dmitry A. Kazakov]

On Thu, 10 Nov 2005 16:25:09 +0800, bubble wrote:

> I guess functin "&" for string type may have potential  problem in gnat 
> windows editions.
> does any body know the problem and give me some suggestion.
> thanks

It doesn't look like either Ada or GNAT problem. You have a Windows thread
[started from Visual Basic] which stack is too small. Under Windows, a DLL
has no influence on the stack size of the caller's threads. At the time
point it is too late to change anything. The caller's thread is already
running. So don't create large objects on the stack. It is a bad idea.
However, refer to Visual Basic documentation, you will definitely find a
way of increasing the stack of Basic threads [if there could be more than
one.] For further information look MSDN: "Platform SDK: DLLs, Processes,
and Threads", Thread Stack Size.

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

Re: function "&" for strings type cause memory problem.

[tmoran]

>I test the code snip and I get some problem in the statement, Nstring2 :=
>new String'(String1 & String2) .
   You don't say what the problem is.  I presume it's a Storage_Error,
and not corrupted data.  If it is running out of memory, how big are
String1 and String2?

Re: function "&" for strings type cause memory problem.

[Jeffrey R. Carter]

bubble wrote:

     type access_string is access all String;
>    String1 : String := (1 .. 10_000_000 => 'a');
>    String2 : String := (1 .. 10_000_000 => 'b');
> 
>       Nstring2 := new String'(String1 & String2);

"&" is probably creating its result on the stack, and there's not enough space 
for a 20-million-character string on your stack, resulting in Storage_Error. You 
can check the GNAT sources if you want to be sure.

You could allocate the space and copy the 2 strings in separately, similar to 
what you do in your 1st test.

Do you really have 10-million-character strings, or are you allocating enough 
for the maximum from VB? If the latter, you can allocate just the amount you 
need. Ada is good at that.

-- 
Jeff Carter
"It's symbolic of his struggle against reality."
Monty Python's Life of Brian
78

Re: function "&" for strings type cause memory problem.

[bubble]

dear all:
thank your reply.
correct me if I'm wrong.


maybe the subject should be
 function "&"  crash in thread's stack size is too small, even if you have a 
big heap memory.

I knew to allocate a "large" object in stack is a bad idea.(another 
question:how to define "large"  to stack?)
and I allocate the large object in heap memory  in previous case.
It's seem so beauty :)

if "&" is  creating its result on the stack ,it still has potential risk.

in others.
I don't want to tell my programer:
" you can not use & for string or array,it has 1% probability to crash"

I want to say.
"  & for string or array merge don't crash, but you will get worst 
performace"
" you can change code and you will get better performance"


To Jeff and Dmitry.

in fact.
the the kernel(ada part) just crash "few" times.
It work perfectly until now after I change something like new test case .

my string are not so big,
I give you the extreme example.
because I just want to say bugs often happen in extreme case.
and I have not find any documents to increasing stack size in VB6.


please see new test case.

--------for test.adb-----------------------
with Ada.Text_IO;
Use Ada.Text_Io;
With stringFunctionPatch;

procedure test Is
   Type Access_String Is Access String;
   String1 : String := (1 .. 10_000_000 => 'a');
   String2 : String := (1 .. 10_000_000 => 'b');
   function "&" (Left,Right:string)Return String Renames 
StringFunctionPatch."&"; --enable/disable the line

begin
   declare
      Nstring2 : access_string := null;
   begin
      Nstring2 := new String'(String1 & String2);
      Put_Line("Test 2 Passed ");
   end;
end test;



---------------------stringFunctionPatch.ads-------------------
package stringFunctionPatch is
   Function  "&"(Left,Right:string)Return String;
end stringFunctionPatch;



--------------------stringFunctionPatch.adb-------------------
with Ada.Finalization;
With Ada.Unchecked_Deallocation;

package body stringFunctionPatch is
   type string_pointer is access String;
   Procedure  Free Is New Ada.Unchecked_Deallocation(String,String_Pointer);

   type Buffer is new Ada.Finalization.Controlled with record
      Data:string_pointer:=Null;
   end record;

   procedure Finalize   (Object : in out Buffer) Is
   Begin
      Free(Object.Data);
   End;

   function "&" (Left, Right : String) return String Is
      StringBuffer:Buffer;
   Begin
      Stringbuffer.Data:=New String (1 .. Left'Length + Right'Length);
      Stringbuffer.Data.all (1 .. left'Last) := left;
      Stringbuffer.Data.all ( Left'Last+1 .. Left'Last + Right'Last):=Right 
;
      return Stringbuffer.Data.all;
   end "&";

end stringFunctionPatch;

Re: function "&" for strings type cause memory problem.

[Dmitry A. Kazakov]

On Fri, 11 Nov 2005 16:25:21 +0800, bubble wrote:

> maybe the subject should be
>  function "&"  crash in thread's stack size is too small, even if you have a 
> big heap memory.
> 
> I knew to allocate a "large" object in stack is a bad idea.(another 
> question:how to define "large"  to stack?)

Let Si be a set of all objects simultaneously existing in the program P at
its execution state i. Si/|Si| is an average object size. Calculate its
expectation value for all possible states i=1..N. Now if the object's size
deviates from that in more than 3 sigma, the object is called "large".
(:-))

> and I allocate the large object in heap memory  in previous case.
> It's seem so beauty :)

> if "&" is  creating its result on the stack ,it still has potential risk.

Memory allocation is always a risk. An important objective of software
design is to minimize risks. One can ignore allocation issues as long as
objects are small. Otherwise some static analysis is required to ensure
that in any case the memory pool will be large enough to hold all objects.
There is no difference between stack and heap here. Even if, for example,
the heap can be enlarged on demand while the stack not, it is all OS
specific issue.

> in others.
> I don't want to tell my programer:
> " you can not use & for string or array,it has 1% probability to crash"
> 
> I want to say.
> "  & for string or array merge don't crash, but you will get worst 
> performace"
> " you can change code and you will get better performance"

Actually Ada provides 3 types of strings reflecting different memory
management strategies. Reconsider your design. For example, if objects are
large, then you need to drop that nice "functional programming" style, and
switch to hard core in-place operations. That is "Append" instead of "&".
You can also move the burden of allocation to the caller side, which
usually knows it better.

BTW, this is what Microsoft did with you. You are required to specify the
stack size. If something goes wrong, then your program will crash, instead
of showing some worse performance. There will be no any performance.

Basically, you have to decide who is responsible for what.

> To Jeff and Dmitry.
> 
> in fact.
> the the kernel(ada part) just crash "few" times.
> It work perfectly until now after I change something like new test case .
>
> my string are not so big,
> I give you the extreme example.
> because I just want to say bugs often happen in extreme case.
> and I have not find any documents to increasing stack size in VB6.

Well, should it be Visual Basic? OK, you need not answer this! (:-))

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

Re: function "&" for strings type cause memory problem.

[bubble]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 
???????:1fxvr41a6cj64$.1cin7p2ro7ua2$.dlg@40tude.net...
> On Fri, 11 Nov 2005 16:25:21 +0800, bubble wrote:

> Let Si be a set of all objects simultaneously existing in the program P at
> its execution state i. Si/|Si| is an average object size. Calculate its
> expectation value for all possible states i=1..N. Now if the object's size
> deviates from that in more than 3 sigma, the object is called "large".
> (:-))

Wow! so interesting define and good idea.
if S ~ Normal distribution,thery are 99.73% in 3 sigma ,
maybe 2.5 sigma is big.


>> and I allocate the large object in heap memory  in previous case.
>> It's seem so beauty :)
>
>> if "&" is  creating its result on the stack ,it still has potential risk.
>
> Memory allocation is always a risk. An important objective of software
> design is to minimize risks. One can ignore allocation issues as long as
> objects are small. Otherwise some static analysis is required to ensure
> that in any case the memory pool will be large enough to hold all objects.
> There is no difference between stack and heap here. Even if, for example,
> the heap can be enlarged on demand while the stack not, it is all OS
> specific issue.
>
> Actually Ada provides 3 types of strings reflecting different memory
> management strategies. Reconsider your design. For example, if objects are
> large, then you need to drop that nice "functional programming" style, and
> switch to hard core in-place operations. That is "Append" instead of "&".
> You can also move the burden of allocation to the caller side, which
> usually knows it better.
>
> BTW, this is what Microsoft did with you. You are required to specify the
> stack size. If something goes wrong, then your program will crash, instead
> of showing some worse performance. There will be no any performance.
>
> Basically, you have to decide who is responsible for what.
Agree.
minimizing risk is importing.
sometime ,It difficult to choose which one is best.
chooses are always trade-off, it's painful.
may be I need rethink the strategies of string types.
and the ARM do not say string merge may raise error when lack of stack 
space.
It's not in my expect.
my expect is worse performace but error.(painful ,painful...)

> Well, should it be Visual Basic? OK, you need not answer this! (:-))

I am lazy man. and my programers have no any IT background.
VB is much easy for us to do "RAPID" GUI development. ^^||
Gwindows/C/C++/java is too hard to non-IT .

Re: function "&" for strings type cause memory problem.

[Dmitry A. Kazakov]

On Fri, 11 Nov 2005 19:55:05 +0800, bubble wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 

> may be I need rethink the strategies of string types.
> and the ARM do not say string merge may raise error when lack of stack 
> space.

Storage_Error is an "implied" exception.

> It's not in my expect.
> my expect is worse performace but error.(painful ,painful...)

It is not always the best possible behavior. The answer depends on whether
appearance of large objects is a design fault or an artefact of deployment
(the machine is too weak for the problem.) In the former case, an earlier
error detection (a crash, yes) is preferable in the long term perspective.
Observe the resource starvation problems many Windows and Linux
applications suffer. Most of them just cover some design faults. MS-Office
loads all opened documents into RAM, should it be so? Too many people are
ready to buy a new workstation each 3-4 years... Last time I stumbled upon
this, was a 13 GB log file (ASCII! (:-)). I was amazed that there were no
editor capable to open it at once. The best I found was UltraEdit. 15-20
years ago nobody would buy such "editor." Technical progress is how people
call it!

>> Well, should it be Visual Basic? OK, you need not answer this! (:-))
> 
> I am lazy man. and my programers have no any IT background.
> VB is much easy for us to do "RAPID" GUI development. ^^||
> Gwindows/C/C++/java is too hard to non-IT .

I am even more lazy, so I'm using raw Windows GUI API even with C++. The
time you might win using VB, Delphi or C++/MFC, you can easily loose if
something turns wrong. The probability of this to happen is inversely
proportional to what customer is ready to pay for the project! (:-))
Usually customers have quite silly requests, looking pretty innocent, from
their point of view of course, but almost impossible to implement without
turning everything upside down. Using Windows GUI I at least know what's
going on. One example: I tend to design GUI working in a polling way as
opposed to usual event-controlled manner. It is more difficult from the
start, but it guaranties definite response time. You'll have more or less
exact figures of how it will work in the worst case, you will also know how
much of CPU time GUI eats, it is fixed. And last but not least, it is
multitasking friendly from the very beginning. This pays off later (or not
(:-)).

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

Re: function "&" for strings type cause memory problem.

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:5h23dl2sire9.hk0tsc5bj1ot.dlg@40tude.net...
> On Fri, 11 Nov 2005 19:55:05 +0800, bubble wrote:
> > may be I need rethink the strategies of string types.
> > and the ARM do not say string merge may raise error when lack of stack
> > space.
>
> Storage_Error is an "implied" exception.

Right. See 11.1(6) in the ARM. Note that 11.1(6) says "any construct"; that
means *anything* may raise Storage_Error, even "null;" or "1 + 1".
Storage_Error is never wrong, at most it is unfriendly.

                                     Randy.