[M3devel] the formsedit crash

[Randy Coleburn]

In my applications, I added code to accept a command line parameter for
increasing the stack size.  Internally, I call the procedures from the
Thread interface to increase the stack size.  I had to do this to avoid
running out of stack, esp. when using Trestle/FormsVBT.  I found that I
had to multiply the stack size by a factor of 7 for most of my stuff to
work.  Note that this increase applies to new threads, not to the
mainline thread.  I don't know of a way to increase the mainline thread
stack while it is running.  
 
If there is a change to the default stack size, anyone who does similar
tricks will need to modify their code, or their shortcuts, or scripts to
avoid making the stack too big.
 
See the code snippet below:
 
      (* stack *)
      IF pp.keywordPresent("-stack")
      THEN (* *)
         TRY (* *)
            stackMult := pp.getNextInt(min := 1, max := 100);
         EXCEPT
          | ParseParams.Error => (* *)
               pp.error("A number in the range [1..100] must be
specified as\n"
                  & "the stack size multiplier after the -stack
option.\n");
         END; (* try *)
      END; (* if *)
      IF stackMult > 1
      THEN
         WITH default = Thread.GetDefaultStackSize(),
              desired = default * stackMult,
              increase = desired - default
         DO
            PutText("Increasing default stack size by a factor of " &
               Fmt.Int(stackMult) & " (" & Fmt.Int(default) & " >>> "
&
               Fmt.Int(desired) & ").\n");
            Thread.IncDefaultStackSize(increase);
         END; (* with *)
         WITH default = Thread.GetDefaultStackSize()
         DO
            PutText("Thread stacks are now " & Fmt.Int(default) & "
bytes.\n");
         END; (* with *)
      END; (* if *)
 
Regards,
Randy Coleburn

>>> Jay K <jay.krell at cornell.edu> 7/27/2009 11:24 AM >>>

I don't think this is a stack overflow but I will try that.
We should probably drastically increase the defaults.
Like make them match whatever the underlying platform uses, or just
make 
  sure that unless the user intercedes, that we don't either.


The whole notion of a limited size stack is pretty flawed imho.
And much worse if you engage in reducing it from the default.
How much stack do I need to leave for fopen to work?
What do I do when I run out of stack? On NT you can detect and handle
it, but it is too tricky.
Personally I try to use very little stack, and don't use recursion - if
I must use a "heap allocated stack" (e.g. std::stack<> in C++).
I understand though that the machine stack is tremendously faster than
anything heap-based (at least in non-gc environments, gc heap alloc can
be fast, if you don't mind the extra work for the gc to later clean it
up..and if the usage is actually lifo...)


Granted, if I'm "just doing a bunch of math" and don't call into code I
don't control, then it becomes more tenable. Still hard to pick a size
that is portable, though multiplying by sizeof(void*) helps.
What if I use TRY? That uses a highly platform-specific and often
fairly large amount of stack.


- Jay


----------------------------------------
> Date: Mon, 27 Jul 2009 16:53:08 +0200
> From: wagner at elegosoft.com 
> To: m3devel at elegosoft.com 
> Subject: Re: [M3devel] the formsedit crash
>
> Quoting Tony Hosking :
>
>> Not sure if doing it that way works. Current default stack size set
in
>> ThreadPThread.m3 is 4096 * ADRSIZE(Word.T). You'll need to try
>> changing it there.
>
> There used to be a procedure IncreaseDefaultStackSize. IITR we
needed
> that for several M3 applications on some platforms several years
ago.
>
> But probably we should also set the default for a target platform
> so that all our own applications are able to run.
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45
86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz:
Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
DE163214194
>

CONFIDENTIALITY NOTICE:  This email and any attachments are intended
solely for the use of the named recipient(s). This e-mail may contain
confidential and/or proprietary information of Scientific Research
Corporation.  If you are not a named recipient, you are prohibited from
making any use of the information in the email and attachments.  If you
believe you have received this email in error, please notify the sender
immediately and permanently delete the email, any attachments, and all
copies thereof from any drives or storage media and destroy any
printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain
technical data subject to U.S export restrictions under the
International Traffic in Arms Regulations (ITAR) or the Export
Administration Regulations (EAR).  Export or transfer of this technical
data and/or related information to any foreign person(s) or entity(ies),
either within the U.S. or outside of the U.S., may require export
authorization by the appropriate U.S. Government agency prior to export
or transfer.  In addition, technical data may not be exported or
transferred to certain countries or specified designated nationals
identified by U.S. embargo controls without prior export authorization. 
By accepting this email and any attachments, all recipients confirm that
they understand and will comply with all applicable ITAR, EAR and
embargo compliance requirements.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090727/ed17612c/attachment-0002.html>