Problem with Control stack

[Prof. Dr. Johannes Grabmeier privat]

Dear all,

in my revision work for finite fields from time to time I get Control
stack exhausted without finding the problem which causes it. (Same
computation in the unchanged current world computes correctly)

Two questions:

1. How can I modify in LISP the debugging to check whether one simply
has to change the behavoiur (debug level 2 ??)

2. How can I trace the in the debugging mode to find out the reason for
this error.

Thanks

Johannes


P.S: Have FriCAS 1.3.6 on SBCL 1.3.14 on a MacBook.



(6) -> G := FF(11,20)

   (6)  FiniteField(11,20)
                                                                                         
Type: Type
(7) -> a : G := random()

   (7)
        19       18      17      16    15    14       13      12     
11      10       8      7      6
     2 α   + 10 α   + 7 α   + 3 α   + α   + α   + 10 α   + 9 α   + 4 α  
+ 7 α   + 10 α  + 4 α  + 5 α
   +
        5       4    3      2
     3 α  + 10 α  + α  + 5 α  + 9 α + 6
                                                                           
Type: FiniteField(11,20)
(8) -> discreteLog a
   Discrete logarithm tables initialized
INFO: Control stack guard page unprotected
Control stack guard page temporarily disabled: proceed with caution

   >> System error:
   Control stack exhausted (no more space for function call frames).
This is probably due to heavily nested or infinitely recursive function
calls, or a tail call that SBCL cannot or has not optimized away.

PROCEED WITH CAUTION.

--
Mit freundlichen Grüßen

Johannes Grabmeier

Prof. Dr. Johannes Grabmeier
Köckstraße 1, D-94469 Deggendorf
Tel. +49-(0)-991-2979584, Tel. +49-(0)-151-681-70756
Tel. +49-(0)-991-3615-141 (d), Fax: +49-(0)-32224-192688

[Neven Sajko]

I can not help you with debug mode, but if you want to increase the
stack size at compile time (for SBCL), see this:

https://github.com/fricas/fricas/blob/master/INSTALL#L301

You may need to increase the '512' parameter.

Regards,
Neven Sajko

[Prof. Dr. Johannes Grabmeier FW]

thanks, but this feature seems to be not available:


Report bugs to <fricas...@googlegroups.com>.
~/Downloads/fricas-1.3.6$ ./configure  --control-stack-size 512
configure: error: unrecognized option: `--control-stack-size'
Try `./configure --help' for more information
~/Downloads/fricas-1.3.6$



Am 25.03.20 um 17:50 schrieb Neven Sajko:

Fraktionsvorsitzender
FREIE WÄHLER, Stadtrat Deggendorf

Prof. Dr. Johannes Grabmeier
Köckstraße 1, D-94469 Deggendorf
Tel. +49-(0)-991-2979584, Tel. +49-(0)-151-681-70756

Fax: +49-(0)-991-2979592

[Grégory Vanuxem]

Hello,

Note the single quotes :

'--with-lisp=sbcl --control-stack-size 512 --dynamic-space-size 6000'

Cheers,

Greg

--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/7988a5dd-51aa-d00f-7fca-f07462e58323%40grabmeier.net.

[Ralf Hemmecke]

> '--with-lisp=sbcl --control-stack-size 512 --dynamic-space-size 6000'

What about

./configure --with-lisp='sbcl --control-stack-size 512
--dynamic-space-size 6000'

i.e. the quotes behind --with-lisp= ? ;-)

Ralf

[Neven Sajko]

It all depends on what do people consider most readable, I guess.

Your proposal of putting the quotes after the equals symbol is
perhaps more familiar from the perspective of other ("real")
programming languages, but it does not really have anything to do
with the Unix Shell language, more specifically the quoting rules. In
this case the quoting serves to remove the special meaning (as the
word separator symbol) from the space (' ') character, so a full word
that includes the space characters could be formed. Thus it is
possible to either just quote the spaces, quote the entire word, or
anything in between. I think it makes sense to choose one of the
"extremal" choices - namely, quoting the full word. This most clearly
presents to the reader what actually *is* the full word, as it is
written out explicitly and contiguously (without any quotes in
between).

Your solution, on the other hand, places emphasis on the semantical
importance of the part after the equals sign as an argument to sbcl,
but the shell does not itself know anything about that ...

All of this is of minimal importance, of course ;)

Regards,
Neven Sajko

[Waldek Hebisch]

On Fri, Mar 27, 2020 at 07:16:15PM +0100, Prof. Dr. Johannes Grabmeier FW wrote:
>
> Am 25.03.20 um 17:50 schrieb Neven Sajko:
> > On Wed, 25 Mar 2020 at 12:07, Prof. Dr. Johannes Grabmeier privat
> > <joha...@grabmeier.net> wrote:
> >> Dear all,
> >>
> >> in my revision work for finite fields from time to time I get Control
> >> stack exhausted without finding the problem which causes it. (Same
> >> computation in the unchanged current world computes correctly)
> >>
> >> Two questions:
> >>
> >> 1. How can I modify in LISP the debugging to check whether one simply
> >> has to change the behavoiur (debug level 2 ??)
> >>
> >> 2. How can I trace the in the debugging mode to find out the reason for
> >> this error.

I can not read orignal message so I am replying to this one.
To debug stack overflow in sbcl I do:

)set break break

ater running problematic code I get Lisp debugger prompt.
At Lisp debugger prompt I type semthing like:

backtrace 20

Note: number indicates how many calls will be printed,
if you request too much you may crash debugger. And even
if debugger work you probably do not want to see all
few thousends of calls.

To get more condesed output befor 'backtrace' command
I frequently use:

(setf sb-ext:*debug-print-variable-alist*
'((*print-array* . nil) (*print-length* . 10)))

From backtrace it should be clear which routine is responsible.
Once we know which domain/package is involved I use
'script' command to capture output to file and
use ')trace' to trace given constructor. If routines
in question are internal I termporarly export them.

For example, in recent problem reported by Nasser Abbasi
we have:

(1) -> )set break break
(1) -> integrate(sin(a+1/2*%i*log(c*x^2)),x)

INFO: Control stack guard page unprotected
Control stack guard page temporarily disabled: proceed with caution

debugger invoked on a SB-KERNEL::CONTROL-STACK-EXHAUSTED in thread
#<THREAD "main thread" RUNNING {1002BAEDE3}>:

Control stack exhausted (no more space for function call frames).
This is probably due to heavily nested or infinitely recursive function
calls, or a tail call that SBCL cannot or has not optimized away.

PROCEED WITH CAUTION.

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

(no restarts: If you didn't do this on purpose, please report it as a bug.)

(SB-KERNEL::CONTROL-STACK-EXHAUSTED-ERROR)
0] (setf sb-ext:*debug-print-variable-alist*
'((*print-array* . nil) (*print-length* . 10)))

((*PRINT-ARRAY*) (*PRINT-LENGTH* . 10))
0] backtrace 20

Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {1002BAEDE3}>
0: (SB-KERNEL::CONTROL-STACK-EXHAUSTED-ERROR)
1: ("foreign function: call_into_lisp")
2: ("foreign function: post_signal_tramp")
3: (|FRAC;cancelGcd| (1 . 1) #<(SIMPLE-VECTOR 168) {1003931F2F}>)
4: (|FRAC;-;3$;23| (1 . 1) (1 . 1) #<(SIMPLE-VECTOR 168) {1003931F2F}>)
5: (|COMPLEX;-;3$;15| ((1 . 1) 0 . 1) ((1 . 1) 0 . 1) #<(SIMPLE-VECTOR 97) {100391DB3F}>)
6: (|SMP;-;3$;30| (0 (1 . 1) 0 . 1) (0 (1 . 1) 0 . 1) #<(SIMPLE-VECTOR 237) {10039316EF}>)
7: (|FRAC;-;3$;23| (#1=(0 (1 . 1) 0 . 1) . #1#) (#1=(0 (1 . 1) 0 . 1) . #1#) #<(SIMPLE-VECTOR 168) {1003A8E1CF}>)
8: (|EXPR;-;3$;15| (#1=(0 (1 . 1) 0 . 1) . #1#) (#1=(0 (1 . 1) 0 . 1) . #1#) #<(SIMPLE-VECTOR 643) {100391C68F}>)
9: (|EXPR;=;2$B;23| (#1=(0 (1 . 1) 0 . 1) . #1#) (#1=(0 (1 . 1) 0 . 1) . #1#) #<(SIMPLE-VECTOR 643) {100391C68F}>)
10: (|FM;*;R2$;3| (#1=(0 (1 . 1) 0 . 1) . #1#) ((0 (0 (1 . 1) . #1=(0 . 1)) 0 (1 . 1) . #1#)) #<(SIMPLE-VECTOR 61) {1003AA04AF}>)
11: (|UPOLYC-;differentiate;SM2S;31| #<unavailable argument> (#<FUNCTION |RDEPAR;do_param_rde!0|> . #<(SIMPLE-VECTOR 2) {1004A21C1F}>) ((0 #1=(0 (1 . 1) 0 . 1) . #1#)) #<(SIMPLE-VECTOR 198) {1003A9B9DF}>)
12: (|RDEPAR;param_SPDE| #<unavailable argument> #<unavailable argument> #<unavailable argument> 2 (#<FUNCTION |RDEPAR;do_param_rde!1|> . #<(SIMPLE-VECTOR 3) {1002DCC03F}>) (#<FUNCTION |RDEPAR;do_param_rde!3|> . #<(SIMPLE-VECTOR 2) {1002DCDB9F}>) (#<FUNCTION |RDEPAR;do_SPDE_prim!0|> . #<(SIMPLE-VECTOR 9) {1004A21B6F}>) |x| #<(SIMPLE-VECTOR 237) {10037F810F}>)
13: (|RDEPAR;do_SPDE_prim| ((0 #1=(0 (1 . 1) 0 . 1) . #1#)) (NIL (0 #1=(0 (1 . 1) 0 . 1) . #1#)) NIL ((((1 (0 # 1 . 2) . #1=(0 # 0 . 1))) (0 #1# . #1#))) #S(SPAD-KERNEL :OP #<(SIMPLE-VECTOR 3) {1003AA775F}> :ARG NIL :NEST 1) NIL (#<FUNCTION |RDEEFX2;do_param_RDE;2FLSLU;1!0|> . #<(SIMPLE-VECTOR 2) {1002DBDEEF}>) (#<FUNCTION |RDEEFX2;do_param_RDE;2FLSLU;1!1|> . #<(SIMPLE-VECTOR 2) {1002DBDF1F}>) (#<FUNCTION |RDEPAR;do_param_rde!1|> . #<(SIMPLE-VECTOR 3) {1002DCC03F}>) (#<FUNCTION |RDEPAR;do_param_rde!3|> . #<(SIMPLE-VECTOR 2) {1002DCDB9F}>) |x| #<(SIMPLE-VECTOR 237) {10037F810F}>)
14: (|RDEPAR;param_SPDE| #<unavailable argument> #<unavailable argument> #<unavailable argument> 2 (#<FUNCTION |RDEPAR;do_param_rde!1|> . #<(SIMPLE-VECTOR 3) {1002DCC03F}>) (#<FUNCTION |RDEPAR;do_param_rde!3|> . #<(SIMPLE-VECTOR 2) {1002DCDB9F}>) (#<FUNCTION |RDEPAR;do_SPDE_prim!0|> . #<(SIMPLE-VECTOR 9) {1004A209CF}>) |x| #<(SIMPLE-VECTOR 237) {10037F810F}>)
15: (|RDEPAR;do_SPDE_prim| ((0 #1=(0 (1 . 1) 0 . 1) . #1#)) (NIL (0 #1=(0 (1 . 1) 0 . 1) . #1#)) NIL ((((1 (0 # 1 . 2) . #1=(0 # 0 . 1))) (0 #1# . #1#))) #S(SPAD-KERNEL :OP #<(SIMPLE-VECTOR 3) {1003AA775F}> :ARG NIL :NEST 1) NIL (#<FUNCTION |RDEEFX2;do_param_RDE;2FLSLU;1!0|> . #<(SIMPLE-VECTOR 2) {1002DBDEEF}>) (#<FUNCTION |RDEEFX2;do_param_RDE;2FLSLU;1!1|> . #<(SIMPLE-VECTOR 2) {1002DBDF1F}>) (#<FUNCTION |RDEPAR;do_param_rde!1|> . #<(SIMPLE-VECTOR 3) {1002DCC03F}>) (#<FUNCTION |RDEPAR;do_param_rde!3|> . #<(SIMPLE-VECTOR 2) {1002DCDB9F}>) |x| #<(SIMPLE-VECTOR 237) {10037F810F}>)
16: (|RDEPAR;param_SPDE| #<unavailable argument> #<unavailable argument> #<unavailable argument> 2 (#<FUNCTION |RDEPAR;do_param_rde!1|> . #<(SIMPLE-VECTOR 3) {1002DCC03F}>) (#<FUNCTION |RDEPAR;do_param_rde!3|> . #<(SIMPLE-VECTOR 2) {1002DCDB9F}>) (#<FUNCTION |RDEPAR;do_SPDE_prim!0|> . #<(SIMPLE-VECTOR 9) {1004A1F82F}>) |x| #<(SIMPLE-VECTOR 237) {10037F810F}>)
17: (|RDEPAR;do_SPDE_prim| ((0 #1=(0 (1 . 1) 0 . 1) . #1#)) (NIL (0 #1=(0 (1 . 1) 0 . 1) . #1#)) NIL ((((1 (0 # 1 . 2) . #1=(0 # 0 . 1))) (0 #1# . #1#))) #S(SPAD-KERNEL :OP #<(SIMPLE-VECTOR 3) {1003AA775F}> :ARG NIL :NEST 1) NIL (#<FUNCTION |RDEEFX2;do_param_RDE;2FLSLU;1!0|> . #<(SIMPLE-VECTOR 2) {1002DBDEEF}>) (#<FUNCTION |RDEEFX2;do_param_RDE;2FLSLU;1!1|> . #<(SIMPLE-VECTOR 2) {1002DBDF1F}>) (#<FUNCTION |RDEPAR;do_param_rde!1|> . #<(SIMPLE-VECTOR 3) {1002DCC03F}>) (#<FUNCTION |RDEPAR;do_param_rde!3|> . #<(SIMPLE-VECTOR 2) {1002DCDB9F}>) |x| #<(SIMPLE-VECTOR 237) {10037F810F}>)
18: (|RDEPAR;param_SPDE| #<unavailable argument> #<unavailable argument> #<unavailable argument> 2 (#<FUNCTION |RDEPAR;do_param_rde!1|> . #<(SIMPLE-VECTOR 3) {1002DCC03F}>) (#<FUNCTION |RDEPAR;do_param_rde!3|> . #<(SIMPLE-VECTOR 2) {1002DCDB9F}>) (#<FUNCTION |RDEPAR;do_SPDE_prim!0|> . #<(SIMPLE-VECTOR 9) {1004A1E68F}>) |x| #<(SIMPLE-VECTOR 237) {10037F810F}>)
19: (|RDEPAR;do_SPDE_prim| ((0 #1=(0 (1 . 1) 0 . 1) . #1#)) (NIL (0 #1=(0 (1 . 1) 0 . 1) . #1#)) NIL ((((1 (0 # 1 . 2) . #1=(0 # 0 . 1))) (0 #1# . #1#))) #S(SPAD-KERNEL :OP #<(SIMPLE-VECTOR 3) {1003AA775F}> :ARG NIL :NEST 1) NIL (#<FUNCTION |RDEEFX2;do_param_RDE;2FLSLU;1!0|> . #<(SIMPLE-VECTOR 2) {1002DBDEEF}>) (#<FUNCTION |RDEEFX2;do_param_RDE;2FLSLU;1!1|> . #<(SIMPLE-VECTOR 2) {1002DBDF1F}>) (#<FUNCTION |RDEPAR;do_param_rde!1|> . #<(SIMPLE-VECTOR 3) {1002DCC03F}>) (#<FUNCTION |RDEPAR;do_param_rde!3|> . #<(SIMPLE-VECTOR 2) {1002DCDB9F}>) |x| #<(SIMPLE-VECTOR 237) {10037F810F}>)

From this it is clear that problem is in RDEPAR and involves
'param_SPDE' and 'do_SPDE_prim'. Since both are internal
routines I had to modify RDEPAR to export them and then
tracing showed invelved arguments.

--
Waldek Hebisch