stack overflow on running tests

[olNick]

Hi,

While the "cargo run shell" works and I get the familiar prompt and basic commands work Running the test fail as:

cargo run test molt/tests/all.tcl Finished dev [unoptimized + debuginfo] target(s) in 0.11s Running target\debug\moltsh.exe test molt/tests/all.tcl Molt 0.3.2 -- Test Harness

thread 'main' has overflowed its stack

Note, new rust user today, but old tcler...

regards,

[wduquette]

This is almost certainly in the interp.tcl test. There's a test that lets a recursive call recurse until the interpreter's stack-limit is reached. When I run it, it runs to completion; but sometimes, in some environments, you get a Rust panic instead. Reducing the stack-limit prevents the panic. If you're so minded, you could edit molt/tests/interp.tcl to do that, and see what happens.

[olNick]

Thanx for the reply,

Yes it is is interp.tcl test. I just commented it out and passed 404 tes... yeah... I've an old Win7 64 bit machine that snores.

regards, Nikos

P.S If ok by you, I'd like to send you a mail. as I'm kinda looking for programming direction in my old age ...

On Thu, 13 Aug 2020 08:03:12 -0700, Will Duquette wrote:

This is almost certainly in the interp.tcl test. There's a test that lets a recursive call recurse until the interpreter's stack-limit is reached. When I run it, it runs to completion; but sometimes, in some environments, you get a Rust panic instead. Reducing the stack-limit prevents the panic. If you're so minded, you could edit molt/tests/interp.tcl to do that, and see what happens.

-- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or unsubscribe [2].

Links:

[1] https://github.com/wduquette/molt/issues/104#issuecomment-673531469 [2]

https://github.com/notifications/unsubscribe-auth/AG3ZB3EPBU47C5BB3OX257TSAP6DBANCNFSM4P4W7HVQ

[wduquette]

Sure.

On Fri, Aug 14, 2020 at 5:51 AM olNick notifications@github.com wrote:

Thanx for the reply,

Yes it is is interp.tcl test. I just commented it out and passed 404

tes... yeah...

I've an old Win7 64 bit machine that snores.

regards,

Nikos

P.S If ok by you, I'd like to send you a mail. as I'm kinda looking for

programming direction in my old age ...

On Thu, 13 Aug 2020 08:03:12 -0700, Will Duquette wrote:

This is almost certainly in the interp.tcl test. There's a test that

lets a recursive call recurse until the interpreter's stack-limit is

reached. When I run it, it runs to completion; but sometimes, in some

environments, you get a Rust panic instead. Reducing the stack-limit

prevents the panic. If you're so minded, you could edit

molt/tests/interp.tcl to do that, and see what happens.

--

You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub [1], or unsubscribe

[2].

Links:

---

[1]

https://github.com/wduquette/molt/issues/104#issuecomment-673531469

[2]

https://github.com/notifications/unsubscribe-auth/AG3ZB3EPBU47C5BB3OX257TSAP6DBANCNFSM4P4W7HVQ

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/wduquette/molt/issues/104#issuecomment-674058942, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB232VPVJV46BA7X4UC727DSAUXOTANCNFSM4P4W7HVQ .

-- MR. William H. Duquette, OP -- will -at- wjduquette -dot- com

[pisi-de]

Hallo,

got the same stack overflow in the interp.tcl test. Tried setting RUST_MIN_STACK, but that did not help. (I'm on Windows, too) Maybe we should define a configurable stack size as demonstrated in [1] (found in [2]).

1: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ed4766b7217ec58a61eb7ca329e4ca95 2: https://www.reddit.com/r/rust/comments/fdwkda/comment/fjkc72w/?utm_source=share&utm_medium=web2x&context=3

Regards, Christoph

P.S. adding that code snippet for convenience

use std::thread;
use std::mem;

fn main() {
    let handler = thread::Builder::new().stack_size(200*1024*1024).spawn(|| {
        let y:[u64;10000000] = [1;10000000];
        println!("the arrays allocated {} bytes",mem::size_of_val(&y))
    }).expect("can't spawn thread");

    handler.join().expect("something's wrong with the thread");
}