Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segfault with clang 11 on Fedora or Debian Linux #4819

Closed
boxuancui opened this issue Nov 23, 2020 · 8 comments
Closed

Segfault with clang 11 on Fedora or Debian Linux #4819

boxuancui opened this issue Nov 23, 2020 · 8 comments
Milestone

Comments

@boxuancui
Copy link

Hi data.table maintainers, I am the author of DataExplorer, and during my latest submission to CRAN, they notified me of the following error. It happens on Debian/Fedora clang 11 only, and only during the vignettes compilation. While I do not know how to re-produce this, since:

  1. I do not have a clang 11 Debian/Fedora machine.
  2. I did many rounds of testing on RHub, and nothing like this were reported.

I am wondering if you guys have any clues or know what could potentially be a next step for me. I also tried to search on past issues and noticed something similar in #2707. Not sure if it is valid, but looks like something similar. Thank you!

Error(s) in re-building vignettes:
--- re-building ‘dataexplorer-intro.Rmd’ using rmarkdown

*** caught segfault ***
address (nil), cause 'unknown'

Traceback:
1: fsort(as.numeric(irows))
2: [.data.table(dt, variable %in% feature_names[x])
3: dt[variable %in% feature_names[x]]
4: ggplot(dt[variable %in% feature_names[x]], aes(x = value))
5: FUN(X[[i]], ...)
6: lapply(X = X, FUN = FUN)
7: .lapply(parallel = parallel, X = layout, FUN = function(x) {
ggplot(dt[variable %in% feature_names[x]], aes(x = value)) +
do.call("geom_histogram", c(na.rm = TRUE, geom_histogram_args)) +
do.call(paste0("scale_x_", scale_x), list()) + ylab("Frequency")})
8: plot_histogram(final_data, nrow = 3L, ncol = 3L)

@MichaelChirico
Copy link
Member

Hi Boxuan, have you installed against latest master? this was merged last week & I think is relevant:

#4808

@jangorecki
Copy link
Member

jangorecki commented Nov 23, 2020

Agree with Michael.
Traceback shows fsort clearly, and this is what we observed as well, see #4786.
You may be able to reproduce the problem using this docker image which uses clang-11

docker run -it registry.gitlab.com/jangorecki/dockerfiles/r-devel-clang /bin/bash

You may need to run it on multiple core (5-6 threads should do) machine.

I submitted question to r-hub about clang-11 job but they seems to be unresponsive on github: r-hub/rhub-linux-builders#53

@jangorecki jangorecki added this to the 1.13.3 milestone Nov 23, 2020
@boxuancui
Copy link
Author

Thank you both! Do you roughly know when v1.13.3 will be released to CRAN, so that I can plan for my submission as well? Looks like I can't release with remote dependencies.

@jangorecki
Copy link
Member

jangorecki commented Nov 23, 2020

@boxuancui It is possible to release to CRAN with a remote dependency, although this is officially supported only for Suggested dependencies and your package do import data.table. The fact that a dependency is on CRAN already could eventually make that possible also for Imported dependency. The change would look like:

Imports:
  data.table (>= 1.13.3)
Additional_repositories: https://Rdatatable.gitlab.io/data.table

Anyway, I recommend not to release to CRAN like that but wait for data.table 1.13.4 to be released. @mattdowle any idea when that could happen?

@boxuancui
Copy link
Author

@jangorecki Thanks for the info! However, my package was recently archived because I didn't fix a check results error in time. I really would like to have the package back online as soon as possible. However, if 1.13.4 is not that far away, I can certainly wait.

@mattdowle
Copy link
Member

@boxuancui Really sorry for the impact. 1.13.4 should be on CRAN within a few weeks. When you resubmit your package please include data.table (>= 1.13.4) in DESCRIPTION. We saw recently that CRAN removed another package (POUMM) for similar reasons (data.table impacting it), and with only 2 weeks notice too. In your case, just why a package has to be removed from CRAN given that it only fails in the very latest version of clang, seems excessive to me.

@boxuancui
Copy link
Author

boxuancui commented Nov 23, 2020

@mattdowle Totally agreed! And FYI, my package was working fine. It just generated 2 warnings during vignette building! Anyway, thank you all so much for everyone's help! I will wait for 1.13.4.

@mattdowle
Copy link
Member

@boxuancui 1.13.4 has been submitted to CRAN today. It can take 3-7 days from here to settle down on CRAN.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants