Bug#947001: Tests segfaults (since the r-base-core update?)

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#947001: Tests segfaults (since the r-base-core update?)

Sebastien Bacher-2
Package: r-bioc-iranges
Version: 2.20.1-1

The autopkgtest started failing on a segfault
https://ci.debian.net/packages/r/r-bioc-iranges/unstable/amd64/

It seems to have started with the r-base update
-r-base-core 3.6.1-7
+r-base-core 3.6.1.20191206-1

Reply | Threaded
Open this post in threaded view
|

Bug#947001: IRanges segfaults after R was upgraded in Debian (Was: Bug#947001: Tests segfaults (since the r-base-core update?))

Andreas Tille-5
Control: tags -1 upstream
Control: forwarded -1 Bioconductor Package Maintainer <[hidden email]>

Hi,

as you can read below the test suite of IRanges in Debian started failing
after r-base-core was upgraded.  A complete build log can be found here

   https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-bioc-iranges/3717079/log.gz

which says at the end:

...
> IRanges:::.test()
firstNA = 0 <=> *no* NA/NaN.
firstNA = 0 <=> *no* NA/NaN.
firstNA = 0 <=> *no* NA/NaN.
firstNA = 0 <=> *no* NA/NaN.

 *** caught segfault ***
address 0x55c0daa0aa60, cause 'invalid permissions'

Traceback:
 1: FUN(X[[i]], ...)
 2: FUN(X[[i]], ...)
 3: lapply(as.list(X), match.fun(FUN), ...)
 4: lapply(as.list(X), match.fun(FUN), ...)
 5: lapply(x, runmed, k = k, endrule = match.arg(endrule), algorithm = algorithm,     print.level = print.level)
 6: lapply(x, runmed, k = k, endrule = match.arg(endrule), algorithm = algorithm,     print.level = print.level)
 7: .dotargsAsList("numeric", ...)
 8: NumericList(lapply(x, runmed, k = k, endrule = match.arg(endrule),     algorithm = algorithm, print.level = print.level), compress = FALSE)
 9: runmed(list3, 7)
10: runmed(list3, 7)
11: as.list(runmed(list3, 7))
12: checkIdentical(as.list(runmed(list3, 7)), lapply(list3, function(x) {    y <- runmed(x, 7)    if (type != "RleList")         y <- as.vector(y)    y}))
13: func()
14: system.time(func(), gcFirst = RUnitEnv$.gcBeforeTest)
15: doTryCatch(return(expr), name, parentenv, handler)
16: tryCatchOne(expr, names, parentenv, handlers[[1L]])
17: tryCatchList(expr, classes, parentenv, handlers)
18: tryCatch(expr, error = function(e) {    call <- conditionCall(e)    if (!is.null(call)) {        if (identical(call[[1L]], quote(doTryCatch)))             call <- sys.call(-4L)        dcall <- deparse(call)[1L]        prefix <- paste("Error in", dcall, ": ")        LONG <- 75L        sm <- strsplit(conditionMessage(e), "\n")[[1L]]        w <- 14L + nchar(dcall, type = "w") + nchar(sm[1L], type = "w")        if (is.na(w))             w <- 14L + nchar(dcall, type = "b") + nchar(sm[1L],                 type = "b")        if (w > LONG)             prefix <- paste0(prefix, "\n  ")    }    else prefix <- "Error : "    msg <- paste0(prefix, conditionMessage(e), "\n")    .Internal(seterrmessage(msg[1L]))    if (!silent && isTRUE(getOption("show.error.messages"))) {        cat(msg, file = outFile)        .Internal(printDeferredWarnings())    }    invisible(structure(msg, class = "try-error", condition = e))})
19: try(system.time(func(), gcFirst = RUnitEnv$.gcBeforeTest))
20: .executeTestCase(funcName, envir = sandbox, setUpFunc = .setUp,     tearDownFunc = .tearDown)
21: .sourceTestFile(testFile, testSuite$testFuncRegexp)
22: RUnit::runTestSuite(suite)
23: BiocGenerics:::testPackage("IRanges")
24: IRanges:::.test()
An irrecoverable exception occurred. R is aborting now ...
Segmentation fault


Any idea how to fix this?  BTW, there is a similar effect with
S4Vectors.  May be that's related.

Kind regards

       Andreas.



On Thu, Dec 19, 2019 at 11:23:18AM +0100, Sebastien Bacher wrote:

> Package: r-bioc-iranges
> Version: 2.20.1-1
>
> The autopkgtest started failing on a segfault
> https://ci.debian.net/packages/r/r-bioc-iranges/unstable/amd64/
>
> It seems to have started with the r-base update
> -r-base-core 3.6.1-7
> +r-base-core 3.6.1.20191206-1
>
> _______________________________________________
> R-pkg-team mailing list
> [hidden email]
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Bug#947001: r-base blocked by r-bioc-{iranges,s4vectors}

Graham Inggs-3
In reply to this post by Sebastien Bacher-2
In Ubuntu, r-bioc-iranges and r-bioc-s4vectors autopkgtests failed
with r-base/3.6.2-1.

However, after the upload of r-base/3.6.2-2, both autopkgtests passed
on ppc64el [1][2].

Could this be related to the change for ppc64 [3]?


[1] http://autopkgtest.ubuntu.com/packages/r/r-bioc-iranges/focal/ppc64el
[2] http://autopkgtest.ubuntu.com/packages/r/r-bioc-s4vectors/focal/ppc64el
[3] https://salsa.debian.org/edd/r-base/commit/de0abdf806db7c2eebf341ff3040b11e971cef9d

Reply | Threaded
Open this post in threaded view
|

Bug#947001: r-base blocked by r-bioc-{iranges,s4vectors}

Dirk Eddelbuettel

On 22 December 2019 at 14:09, Graham Inggs wrote:
| In Ubuntu, r-bioc-iranges and r-bioc-s4vectors autopkgtests failed
| with r-base/3.6.2-1.
|
| However, after the upload of r-base/3.6.2-2, both autopkgtests passed
| on ppc64el [1][2].
|
| Could this be related to the change for ppc64 [3]?

Possibly, yes.  R 3.6.2 brought that change, it was reported as an issue
upstream by the RedHat folks, but also integrated the changes pretty quickly
(and about the same time as upstream).

So do we "just" need to tickle rebuilds for these two?  If so, how?

Dirk
 
| [1] http://autopkgtest.ubuntu.com/packages/r/r-bioc-iranges/focal/ppc64el
| [2] http://autopkgtest.ubuntu.com/packages/r/r-bioc-s4vectors/focal/ppc64el
| [3] https://salsa.debian.org/edd/r-base/commit/de0abdf806db7c2eebf341ff3040b11e971cef9d

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#947001: r-base blocked by r-bioc-{iranges,s4vectors}

Dirk Eddelbuettel

On 22 December 2019 at 08:02, Dirk Eddelbuettel wrote:
|
| On 22 December 2019 at 14:09, Graham Inggs wrote:
| | In Ubuntu, r-bioc-iranges and r-bioc-s4vectors autopkgtests failed
| | with r-base/3.6.2-1.
| |
| | However, after the upload of r-base/3.6.2-2, both autopkgtests passed
| | on ppc64el [1][2].
| |
| | Could this be related to the change for ppc64 [3]?
|
| Possibly, yes.  R 3.6.2 brought that change, it was reported as an issue
| upstream by the RedHat folks, but also integrated the changes pretty quickly
| (and about the same time as upstream).
 
On the other hand the ppc64 is one of 'blocking compilation' so it can't
really segfaults at tests.

Dirk

| So do we "just" need to tickle rebuilds for these two?  If so, how?
|
| Dirk
|  
| | [1] http://autopkgtest.ubuntu.com/packages/r/r-bioc-iranges/focal/ppc64el
| | [2] http://autopkgtest.ubuntu.com/packages/r/r-bioc-s4vectors/focal/ppc64el
| | [3] https://salsa.debian.org/edd/r-base/commit/de0abdf806db7c2eebf341ff3040b11e971cef9d
|
| --
| http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#947001: r-base blocked by r-bioc-{iranges,s4vectors}

Graham Inggs-3
On Sun, 22 Dec 2019 at 16:10, Dirk Eddelbuettel <[hidden email]> wrote:
> On the other hand the ppc64 is one of 'blocking compilation' so it can't
> really segfaults at tests.

I don't know what that means, but both the r-bioc-iranges and
r-bioc-s4vectors autopkgtests with r-base/3.6.2-1 on ppc64el showed:

An irrecoverable exception occurred. R is aborting now ...
Segmentation fault (core dumped)

Reply | Threaded
Open this post in threaded view
|

Bug#947001: r-base blocked by r-bioc-{iranges,s4vectors}

Dirk Eddelbuettel

On 22 December 2019 at 16:55, Graham Inggs wrote:
| On Sun, 22 Dec 2019 at 16:10, Dirk Eddelbuettel <[hidden email]> wrote:
| > On the other hand the ppc64 is one of 'blocking compilation' so it can't
| > really segfaults at tests.
|
| I don't know what that means, but both the r-bioc-iranges and
| r-bioc-s4vectors autopkgtests with r-base/3.6.2-1 on ppc64el showed:
|
| An irrecoverable exception occurred. R is aborting now ...
| Segmentation fault (core dumped)

ppc64 had a 'cannot compile' issue. See eg this email + thread by Tom Callaway
https://stat.ethz.ch/pipermail/r-devel/2019-December/078801.html

So that would not be the same issue as these segfaults. I have seen segfaults
like this with C++ code, frequently just requiring a recompilation. CRAN and
BioC code is generally well enough tested at those repos to not just randomly
segfault.

But these are not my packages, and I do not use them so I am shooting a
little from the hip here.  And it looks like iranges depends on s4vectors, so
presumably only the latter needs a fix or rebuild?

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#947001: [R-pkg-team] Bug#947001: r-base blocked by r-bioc-{iranges, s4vectors}

Graham Inggs-3
In reply to this post by Graham Inggs-3
On Sun, 22 Dec 2019 at 17:04, Graham Inggs <[hidden email]> wrote:
> On Sun, 22 Dec 2019 at 16:10, Dirk Eddelbuettel <[hidden email]> wrote:
> > On the other hand the ppc64 is one of 'blocking compilation' so it can't
> > really segfaults at tests.
>
> I don't know what that means, but both the r-bioc-iranges and
> r-bioc-s4vectors autopkgtests with r-base/3.6.2-1 on ppc64el showed:
>
> An irrecoverable exception occurred. R is aborting now ...
> Segmentation fault (core dumped)

Looking closer, the failing tests above were with
r-base/3.6.2-1build1, which was uploaded by an Ubuntu developer and
included the PPC fix.

No autopkgtests were run with r-base/3.6.2-1 in Ubuntu because it
didn't build on all architectures.

Autopkgtests continue to pass with r-base/3.6.2-2 on ppc64el, and the
only diff between it and 3.6.2-1build1 is in the changelog [1].
Autopkgtests continue to fail with r-base/3.6.2-2 on amd64, arm64,
armhf and s390x.


[1] http://launchpadlibrarian.net/456137318/r-base_3.6.2-1build1_3.6.2-2.diff.gz

Reply | Threaded
Open this post in threaded view
|

Bug#947001: [R-pkg-team] Bug#947001: r-base blocked by r-bioc-{iranges, s4vectors}

Dirk Eddelbuettel

On 23 December 2019 at 12:43, Graham Inggs wrote:
| On Sun, 22 Dec 2019 at 17:04, Graham Inggs <[hidden email]> wrote:
| > On Sun, 22 Dec 2019 at 16:10, Dirk Eddelbuettel <[hidden email]> wrote:
| > > On the other hand the ppc64 is one of 'blocking compilation' so it can't
| > > really segfaults at tests.
| >
| > I don't know what that means, but both the r-bioc-iranges and
| > r-bioc-s4vectors autopkgtests with r-base/3.6.2-1 on ppc64el showed:
| >
| > An irrecoverable exception occurred. R is aborting now ...
| > Segmentation fault (core dumped)
|
| Looking closer, the failing tests above were with
| r-base/3.6.2-1build1, which was uploaded by an Ubuntu developer and
| included the PPC fix.
|
| No autopkgtests were run with r-base/3.6.2-1 in Ubuntu because it
| didn't build on all architectures.
|
| Autopkgtests continue to pass with r-base/3.6.2-2 on ppc64el, and the
| only diff between it and 3.6.2-1build1 is in the changelog [1].
| Autopkgtests continue to fail with r-base/3.6.2-2 on amd64, arm64,
| armhf and s390x.

I would be very surprised if these were not self-inflicted by us. I know CRAN
(much) better than BioC, but both of them are doing extensive self-tests (and
generally without any arbitrary restrictions, say about timing and versions)
we may impose.

I tried a quick test on a Debian testing machine I use for (extensive)
reverse dependency checks (at the upstream level) but it was incloncusive.

Still a pity that r-base is held back by this.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#947001: [R-pkg-team] Bug#947001: r-base blocked by r-bioc-{iranges, s4vectors}

Graham Inggs-3
Control: severity -1 serious

On Mon, 23 Dec 2019 at 22:30, Dirk Eddelbuettel <[hidden email]> wrote:
> I would be very surprised if these were not self-inflicted by us. I know CRAN
> (much) better than BioC, but both of them are doing extensive self-tests (and
> generally without any arbitrary restrictions, say about timing and versions)
> we may impose.

This situation reminds me of #877288, where I believe Debian's
autopkgtests detected the problem before upstream.

> I tried a quick test on a Debian testing machine I use for (extensive)
> reverse dependency checks (at the upstream level) but it was incloncusive.

Hopefully we get an answer from upstream BioConductor soon.

> Still a pity that r-base is held back by this.

This is better than allowing a package that breaks others to migrate
into testing.
If there is no progress for some time, Release Team may remove
r-bioc-iranges and r-bioc-s4vectors from testing to allow r-base to
migrate, as in any other transition.

Reply | Threaded
Open this post in threaded view
|

Bug#947001: Bug#947004: S4Vectors Segmentation fault after r-base-core update (Was: Bug#947004: Tests segfaults (since the r-base-core update?))

Dylan Aïssi-3
In reply to this post by Sebastien Bacher-2
Hi,

Le ven. 10 janv. 2020 à 00:30, Pages, Herve <[hidden email]> a écrit :
> Based on the traceback the error happens during evaluation of the 1st
> argument ('target') passed to checkEqualsNumeric(), that is, during
> evaluation of 'runmed(y, 7)'. Since this involves base R code only
> (runmed() is implemented in the stats package) I would say that it's not
> immediately obvious that the problem is in my court.

Thanks Hervé for this.

I just updated how to run Debian autopkgtests [1-2] by replacing:

> LC_ALL=C R --no-save <<EOT
> require("S4Vectors")
> S4Vectors:::.test()
> EOT

with

> LC_ALL=C.UTF-8 R --no-save -e 'BiocGenerics:::testPackage("S4Vectors")'

which seems to be the recommended way to run tests for bioconductor
packages. And now, there is no segfault anymore for S4vectors but
IRanges is still crashing. Should we upload these fixes into
Debian/unstable?

Best,
Dylan

[1] https://salsa.debian.org/r-pkg-team/r-bioc-s4vectors/commit/51b8ca2571dac1685e748679568edf4463cbfd59
[2] https://salsa.debian.org/r-pkg-team/r-bioc-iranges/commit/06a76a22fa236f919fc0038c5c01aec35ec2ecda
[3] https://bioconductor.org/developers/how-to/unitTesting-guidelines/#RUnitConventions

Reply | Threaded
Open this post in threaded view
|

Bug#947001: Bug#947004: S4Vectors Segmentation fault after r-base-core update (Was: Bug#947004: Tests segfaults (since the r-base-core update?))

Andreas Tille-2
On Sat, Jan 11, 2020 at 10:12:48AM +0100, Dylan Aïssi wrote:
> Le ven. 10 janv. 2020 à 00:30, Pages, Herve <[hidden email]> a écrit :
> > Based on the traceback the error happens during evaluation of the 1st
> > argument ('target') passed to checkEqualsNumeric(), that is, during
> > evaluation of 'runmed(y, 7)'. Since this involves base R code only
> > (runmed() is implemented in the stats package) I would say that it's not
> > immediately obvious that the problem is in my court.
>
> Thanks Hervé for this.

+1
 

> I just updated how to run Debian autopkgtests [1-2] by replacing:
>
> > LC_ALL=C R --no-save <<EOT
> > require("S4Vectors")
> > S4Vectors:::.test()
> > EOT
>
> with
>
> > LC_ALL=C.UTF-8 R --no-save -e 'BiocGenerics:::testPackage("S4Vectors")'
>
> which seems to be the recommended way to run tests for bioconductor
> packages. And now, there is no segfault anymore for S4vectors but
> IRanges is still crashing. Should we upload these fixes into
> Debian/unstable?

Thanks for the fix - IMHO it makes sense to upload in any way if we
are doing something differently than it should be done.  Would you
mind checking other BioConductor packages as well?

Kind regards and thanks for your investigation

      Andreas.
 
> [1] https://salsa.debian.org/r-pkg-team/r-bioc-s4vectors/commit/51b8ca2571dac1685e748679568edf4463cbfd59
> [2] https://salsa.debian.org/r-pkg-team/r-bioc-iranges/commit/06a76a22fa236f919fc0038c5c01aec35ec2ecda
> [3] https://bioconductor.org/developers/how-to/unitTesting-guidelines/#RUnitConventions

--
http://fam-tille.de

Reply | Threaded
Open this post in threaded view
|

Bug#947001: r-base blocked by r-bioc-{iranges,s4vectors}

Dirk Eddelbuettel
In reply to this post by Sebastien Bacher-2

On 17 January 2020 at 15:20, Charles Plessy wrote:
| fixed 947001 2.20.1-2
| fixed 947004 0.24.2-1
| thanks
|
| Hello everybody,
|
| following Gordon's email, I have source-uploaded r-bioc-iranges
| 2.20.1-2, which contains a few additional changes that were pending in
| the source package's Git repository, and good news: the regression tests
| pass.  r-bioc-s4vectors was uploaded earlier as a new upstream version
| by Dylan, and its tests pass as well.  Autopkgtest form arm64 lag
| behind, but I believe it is not a blocker.
|
| Hopefully, our problem is solved !

Awesome -- Thanks so much!

| (And hopefully, this email marks the beginning of the maybe my possible
| comeback, let's keep fingers crossed.  These source uploads are really
| empowering.)

Fingers crossed :)

Dirk
 
| Have a nice day,
|
| Charles
|
| --
| Charles Plessy                              Akano, Uruma, Okinawa, Japan
| Debian Med packaging team         http://www.debian.org/devel/debian-med
| Tooting from work,           https://mastodon.technology/@charles_plessy
| Tooting from home,                 https://framapiaf.org/@charles_plessy
|

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]