Re: [Rd] [External] R hang/bug with circular references and promises
On Sat, 11 May 2024, Peter Langfelder wrote:
On Sat, May 11, 2024 at 9:34 AM luke-tierney--- via R-devel
wrote:
On Sat, 11 May 2024, Travers Ching wrote:
The following code snippet causes R to hang. This example might be a
bit contrived as I was experimenting and trying to understand
promises, but uses only base R.
This has nothing to do with promises. You created a cycle in the
environment chain. A simpler variant:
e <- new.env()
parent.env(e) <- e
get("x", e)
This will hang and is not interruptable -- loops searching up
environment chains are too speed-critical to check for interrupts. It
is, however, pretty easy to check whether the parent change would
create a cycle and throw an error if it would. Need to think a bit
about exactly where the check should go.
FWIW, the help for parent.env already explicitly warns against using
parent.env <-:
The replacement function ‘parent.env<-’ is extremely dangerous as
it can be used to destructively change environments in ways that
violate assumptions made by the internal C code. It may be
removed in the near future.
Looks like I added that warning 22 years ago, so that should be enough
notice :-). I'll look into removing it now.
Best,
luke
Peter
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] R hang/bug with circular references and promises
On Mon, 13 May 2024 09:54:27 -0500 (CDT) luke-tierney--- via R-devel wrote: > Looks like I added that warning 22 years ago, so that should be enough > notice :-). I'll look into removing it now. Dear Luke, I've got a somewhat niche use case: as a way of protecting myself against rogue *.rds files and vulnerabilities in the C code, I've been manually unserializing "plain" data objects (without anything executable), including environments, in R [1]. I see that SET_ENCLOS() is already commented as "not API and probably should not be <...> used". Do you think there is a way to recreate an environment, taking the REFSXP entries into account, without `parent.env<-`? Would you recommend to abandon the folly of unserializing environments manually? -- Best regards, Ivan [1] https://codeberg.org/aitap/unserializeData/src/commit/33d72705c1ee265349b3e369874ce4b47f9cd358/R/unserialize.R#L289-L313 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] R hang/bug with circular references and promises
On Mon, 13 May 2024, Ivan Krylov wrote: [You don't often get email from ikry...@disroot.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] On Mon, 13 May 2024 09:54:27 -0500 (CDT) luke-tierney--- via R-devel wrote: Looks like I added that warning 22 years ago, so that should be enough notice :-). I'll look into removing it now. For now I have just changed the internal code to throw an error if the change would produce a cycle (r86545). This gives > e <- new.env() > parent.env(e) <- e Error in `parent.env<-`(`*tmp*`, value = ) : cycles in parent chains are not allowed Dear Luke, I've got a somewhat niche use case: as a way of protecting myself against rogue *.rds files and vulnerabilities in the C code, I've been manually unserializing "plain" data objects (without anything executable), including environments, in R [1]. I would try using two passes: create the environments in the first pass and in a second pass, either over the file or a new object with place holders, fill them in. I see that SET_ENCLOS() is already commented as "not API and probably should not be <...> used". Do you think there is a way to recreate an environment, taking the REFSXP entries into account, without `parent.env<-`? Would you recommend to abandon the folly of unserializing environments manually? SET_ENCLOS is one of a number of SET... functions that are not in the API and should not be since they are potentially unsafe to use. (One that is in the API and needs to be removed is SET_TYPEOF). So we would like to move them out of installed headers and not export them as entry points. For this particular case most uses I see are something like env = allocSExp(ENVSXP); SET_FRAME(env, R_NilValue); SET_ENCLOS(env, parent); SET_HASHTAB(env, R_NilValue); SET_ATTRIB(env, R_NilValue); which could just use env = R_NewEnv(parent, FALSE, 0); Best, luke -- Best regards, Ivan [1] https://codeberg.org/aitap/unserializeData/src/commit/33d72705c1ee265349b3e369874ce4b47f9cd358/R/unserialize.R#L289-L313 -- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
