scryer-prolog
scryer-prolog copied to clipboard
mthom
thread 'main' panicked at 'Cannot drop a runtime in a context where blocking is not allowed.
I compiled scryer-prolog from source (main branch, today) and I get an error with
` matteo@debian:~/Downloads/scryer-prolog$ ./target/debug/scryer-prolog
?- use_module(library(http/http_open)). true.
?- http_open("https://www.example.com", S, []), get_n_chars(S, N, HTML).
thread 'main' panicked at 'Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.', /home/matteo/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.35.1/src/runtime/blocking/shutdown.rs:51:21
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
My env is
matteo@debian:~/Downloads/scryer-prolog$ ./target/debug/scryer-prolog --version v0.9.3-137-gccf581d8
matteo@debian:~/Downloads/scryer-prolog$ uname -a Linux debian 6.5.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.13-1 (2023-11-29) x86_64 GNU/Linux
matteo@debian:~/Downloads/scryer-prolog$ rustc --version rustc 1.70.0
matteo@debian:~/Downloads/scryer-prolog$ cargo --version cargo 1.69.1
Could you please try to find out which most recent commit introduced this issue?
On OSX, I cannot reproduce the problem with v0.9.3-122-g75302ab7 from a few days ago:
?- http_open("https://www.example.com", S, []), get_n_chars(S, N, HTML).
S = '$stream'(0x7fbef3503398), N = 1256, HTML = "\n
I can replicate it on my computer running master. I'll try to investigate.
I can't replicate it (it works as in the Markus' OSX case) on my Ubuntu 22.04.3; Scryer git-version: "ccf581d"; rustc 1.75.0, compiled using "cargo build --release".
Thank you all for looking into it! It may even be due to different rustc versions; I have:
$ rustc --version rustc 1.72.0 (5680fa18f 2023-08-23)
I tested some older git-versions of the cargo:0.9.3 release with this "http example", I had compiled (with older versions of rustc back then), it all works.
I have to add another fact and (maybe, only maybe, if at all) possibility (aside the combination of the older rustc version with recent Scryer version) from my naive, non-developer prespective: my Ubuntu 22.04.3 LTS has an older version of Linux kernel then the matteoredaelli's "panicked" case.
I can also reproduce this.
.../repos/dev/scryer-prolog> cargo --version
cargo 1.70.0 (ec8a8a0ca 2023-04-25)
.../repos/dev/scryer-prolog> rustc --version
rustc 1.70.0 (90c541806 2023-05-31)
.../repos/dev/scryer-prolog> uname -a
Linux kbook 6.6.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Tue, 02 Jan 2024 02:28:28 +0000 x86_64 GNU/Linux
.../repos/dev/scryer-prolog> scryer-prolog-debug -v
v0.9.3-137-gccf581d8-modified
I can't reproduce it. On a modern Linux (6.6.9) and rustc,cargo 1.75.0 with renewed crates, scryer-prolog: v0.9.3-137-gccf581d8-modified
?- http_open("https://www.example.com", S, []), get_n_chars(S, N, HTML).
S = '$stream'(0x558a1535bee8), N = 1256, HTML = "<!doctype html>\n<ht ...".
I get the same result as @triska except HTML = ...
@flexoron Yes, except that the HTML begins with "<!doctype html>\n<ht ...", but I think it's a "quick abbreviation" in the Markus' case...
I can confirm the Mr. @bakaq's observation in my case/configuration as well. For fun and non-profit I tried the compilation without "--release" and it "panicked" nicely...
PS: I was wondering where is the "debug" folder from, it is from the compilation without the "--release".
I updated to cargo and rustc 1.75.0 and it remains panicking, but only in the debug build. Maybe it's a debug assertion (so it goes away in the release build) from tokio that is checking an invariant that doesn't actually matter in this case for some reason. Or maybe it matters and we have some undefined behavior in our table right now.
I opened a PR in which I no longer get errors in debug builds (some reading here: https://github.com/seanmonstar/reqwest/issues/1233)