Open nileshpatra opened 3 years ago
@nileshpatra Would mind providing some instructions on how to reproduce this? I'm not familiar with this particular tool chain.
@meztez sure, you could
a) create a i386 chroot via debootstrap something like: $ debootstrap --arch i386 sid $
b) Spin up a docker container with a Dockerfile like:
FROM --platform=i386 debian:unstable
RUN apt-get -y update
RUN apt-get install r-base
RUN R -e "install.packages
...... so on ..... and then trigger tests with testthat
Apologies, but I do not have the commands handy, but this should give an idea.
The way I am testing it from a Debian package is like this exactly though you might not need to do this, but still for ref (since these are un-necessary extra steps, and simply doing it with the way upstream tests are run would be easy to test):
$ sudo chroot <chroot-path>
# cd /root/
# apt-get install r-cran-plumber r-cran-testthat r-cran-pki r-cran-rmarkdown r-cran-htmlwidgets r-cran-readr
# apt-get source r-cran-plumber
# cd r-cran-plumber-1.1.0/
# bash ./debian/tests/run-unit-test
Please do let me know if you need more information.
@nileshpatra I was able to track down the hang to https://github.com/rstudio/plumber/blob/06e46f3ff5119e5f1cb8af29ef49aecb3cbb932a/tests/testthat/test-plumber-run.R#L4
If you remove test-plumber-run.R, it should not hang. I still have to find out why later is hanging for that long.
if you start R manually then run, it won't hang
library(testthat)
library(plumber)
test_check()
But using the debian run-unit-test script will hang.
@nileshpatra I was able to track down the hang to https://github.com/rstudio/plumber/blob/06e46f3ff5119e5f1cb8af29ef49aecb3cbb932a/tests/testthat/test-plumber-run.R#L4 If you remove test-plumber-run.R, it should not hang. I still have to find out why later is hanging for that long.
@meztez thanks for the heads up!
if you start R manually then run, it won't hang library(testthat) library(plumber) test_check()
I had cloned this upstream repo, switched to tag 1.1.0, and it was still hanging for me -- weird. Would you mind providing the instructions on how you ran this one exactly?
But using the debian run-unit-test script will hang.
The script is essentially doing the exact same thing as running it with R, i.e. copying the tests directory and running testthat.R, which does the same set of operations, as running manually. I'm not very sure why this might not work, if the former did for you. Instructions on how you reproduced this would be appreciated.
But thanks a lot for the heads up, I could exclude this failing test for now in i386 and upload.
@nileshpatra
from a fresh bullseye.
sudo apt update
sudo apt install debootstrap
sudo debootstrap --arch i386 sid $<your_chroot>
sudo chroot <chroot-path>
cd /root/
apt-get install r-cran-plumber r-cran-testthat r-cran-pki r-cran-rmarkdown r-cran-htmlwidgets r-cran-readr
apt-get source r-cran-plumber
cd r-cran-plumber-1.1.0/
Hangs
bash ./debian/tests/run-unit-test
Does not hang
R
setwd("tests")
library("plumber")
library("testthat")
test_check("plumber", reporter = NULL) #to get more info, otherwise test_check("plumber")
Cut the hanging part out
rm /usr/share/doc/r-cran-plumber/tests/testthat/test-plumber-run.R
bash ./debian/tests/run-unit-test
ACK, apologies for the noise. I can confirm that this works on running manually, had to wait for a few more minutes. Then, I've no clue why the script does not work :(
@meztez
If I run this manually in the upstream test directory, then this chokes as well on exactly plumber-run:
$ LC_ALL=C R --no-save < testthat.R
But running via interaction works fine. Not sure why this happens
Reproducible short test:
test.R
library(plumber)
later::later(httpuv::interrupt)
force( pr() %>% pr_run())
Rscript test.R
i386 hangs
amd64 - ok
Yep, it works perfect on amd64. It seems to hang at this on i386:
$ R --no-save < test.R
> library(plumber)
> later::later(httpuv::interrupt)
> force( pr() %>% pr_run())
Running plumber API at http://127.0.0.1:4700
Running swagger Docs at http://127.0.0.1:4700/__docs__/
.... continues running forever
@nileshpatra I don't think later is being executed. Might have to skip on arch. We only use later for that particular test.
@meztez fair enough, I will skip that test on i386. Thanks a lot for all the help! :-)
Wow! Great debugging @meztez and @nileshpatra !
@wch Have you run into this issue before? Works when run manually, but does not work when run non-interactively on i386
.
httpuv::interrupt()
doesn't throw, but rather sets httpuv:::.globals <- TRUE
. So I don't think https://github.com/r-lib/later/pull/102#issuecomment-531027979 is related.
I can't think of any reason why it would behave one way on i386 but another way on amd64. Is the later()
callback not executing at all?
@wch I don't think it is. Tested by replacing with later(~cat("wouf"))
. Did not see any wouf
. I can't figure out yet why it would only fail on i386/debian unstable. Windows i386 works fine.
Hi,
Thanks for your work on plumber. On i386, plumber version 1.1.0 (latest one) tests seem to keep running forever. Eventually, they time out and exits with a failure on Debian CI. Full log can be found here
I confirm that I can also reproduce it locally in an i386 chroot, and hence this failure is not just specific to the CI machine. One notable thing is that this problem does not exist in version 1.0.0 as could be seen here and this is likely a regression with the new one.
Please consider to fix this, I'd really appreciate your help. Thanks again!