similar to: [External] Re: Segfault when parsing UTF-8 text with srcrefs

On 5/28/24 19:35, Hadley Wickham wrote: > Hi all, > > When I run the following code, R segfaults: > > text <- "?" > srcfile <- srcfilecopy("test.r", text) > parse(textConnection(text), srcfile = srcfile) > > It doesn't segfault if text is ASCII, or it's not wrapped in > textConnection, or srcfile isn't set. Thanks, this is

Hi all, When I run the following code, R segfaults: text <- "?" srcfile <- srcfilecopy("test.r", text) parse(textConnection(text), srcfile = srcfile) It doesn't segfault if text is ASCII, or it's not wrapped in textConnection, or srcfile isn't set. Hadley -- http://hadley.nz [[alternative HTML version deleted]]

First, why does this expression have a 'srcref' element: > exprA <- substitute(function(x) a*x, list(a=2)) > print(exprA) function(x) 2 * x > str(as.list(exprA)) List of 4 $ : symbol function $ :Dotted pair list of 1 ..$ x: symbol $ : language 2 * x $ :Class 'srcref' atomic [1:8] 1 20 1 34 20 34 1 1 .. ..- attr(*, "srcfile")=Classes

I saw it also on some of my Ubuntu builds, but the issue went away after a make clean/make, so maybe give that a try. Best, luke On Wed, 24 Apr 2024, Ben Bolker wrote: > I'm using bleeding-edge R-devel, so maybe my build is weird. Can anyone > else reproduce this? > > View() seems to crash on just about anything. > > View(1:3) > *** stack smashing detected ***:

I'm using bleeding-edge R-devel, so maybe my build is weird. Can anyone else reproduce this? View() seems to crash on just about anything. View(1:3) *** stack smashing detected ***: terminated Aborted (core dumped) If I debug(View) I get to the last line of code with nothing obviously looking pathological: Browse[1]> debug: invisible(.External2(C_dataviewer, x, title))

Hello, Consider this file (/tmp/test.R) : <file> f <- function( x, y = 2 ){ z <- x + y print( z ) } </file> I get this in R 2.7.2 : > p <- parse( "/tmp/test.R" ) > str( attr( p, "srcref" ) ) List of 1 $ :Class 'srcref' atomic [1:4] 1 1 4 1 .. ..- attr(*, "srcfile")=Class 'srcfile' length 4 <environment>

In R <= 2.13.x, calling 'parse( con)' where 'con' is a connection, 'options( keep.source)' is TRUE, and default 'srcfile' would preserve the source. In R >= 2.14.1, it doesn't. > tf <- tempfile() > options( keep.source=TRUE) > texto <- c( 'function() { # comment', '}') > parse( text=texto) expression(function() { #

Just checking in to see whether it is intended or not that assigning new formals to a function/closure causes any attributes to be dropped: EXAMPLE: > fcn <- structure(function() {}, foo="foo", class=c("foo")) > str(fcn) function () - attr(*, "srcref")=Class 'srcref' atomic [1:8] 1 18 1 30 18 30 1 1 .. ..- attr(*, "srcfile")=Classes

Dear R-devel, In a package of mine, I use removeSource on expression objects in order to make expressions that are semantically the same serialize to the same byte sequences: https://github.com/cran/depcache/blob/854d68a/R/fixup.R#L8-L34 Today I learned that expressions containing function definitions also contain the source references for the functions, not as an attribute, but as a separate

Hello, It seems that the parsing information attached to expressions parsed by the parse() function when keep.source=TRUE is not provided to the eval() function. Please consider this code: path <- tempfile() code <- '(function() print( str( sys.calls() ) ))()' writeLines(code, path) sys.source(path, envir=globalenv(), keep.source=TRUE) > OUTPUT: Dotted pair list of 4 $ :

On 2025-01-18 8:27 p.m., Ivo Welch wrote: > I am afraid my errors are worse! (so are my postings. I should have > given an example.) > > ``` > x <- 1 > y <- 2 > nofunction("something stupid I am doing!") > z <- 4 > ``` > > and > > ``` >> source("where-is-my-water.R") > Error in nofunction("something stupid I am

If you can afford a dependency on rlang, `rlang::zap_srcref()` deals with this. It's recursive over expression vectors, calls (including calls to `function` and their hidden srcref arg), and function objects. It's implemented in C for efficiency as we found it to be a bottleneck in some applications (IIRC caching). I'd be happy to upstream this in base if R core is interested. Best,

Hi Duncan ? Wonderful. Thank you. Bug or no bug, I think it would be a huge improvement for user-friendliness if R printed the last line by default *every time* a script dies. Most computer languages do so. Should I file it as a request for improvement to the R code development team? Maybe R can be improved at a very low cost to the development team and a very high benefit to newbies.

On 30/03/2023 10:32 a.m., Ivan Krylov wrote: > Dear R-devel, > > In a package of mine, I use removeSource on expression objects in order > to make expressions that are semantically the same serialize to the > same byte sequences: > https://github.com/cran/depcache/blob/854d68a/R/fixup.R#L8-L34 > > Today I learned that expressions containing function definitions also >

Calling parse(text=quote(name)) or text=as.name("name") makes parse() prompt for input from the command line and then it returns a parse of the initial characters of 'name' (depending on how many characters were typed at the prompt). E.g., > parse(text=quote(myName)) ?1/3 expression(myN) attr(,"srcfile") <text> >

On Sun, 19 Jan 2025, Ivo Welch wrote: > Hi Duncan ? Wonderful. Thank you. Bug or no bug, I think it would be > a huge improvement for user-friendliness if R printed the last line by > default *every time* a script dies. Most computer languages do so. > > Should I file it as a request for improvement to the R code > development team? Maybe R can be improved at a very low cost

I noticed the following file descriptor leak when I couldn't remove a package unless I shut down the R session that had loaded and used it. The function that triggered the problem printed the output of a call to parse(). Each time one prints a srcref a connection is opened and not closed. It looks like it happens in as.character.srcref's call to getSrcLines, which has some logic I

Thanks for pointing out the options. Using options(show.error.locations = TRUE) works on Ivo's example, but it doesn't show a location if the error happens in a function that doesn't have srcrefs, because the known location isn't on the top of the stack. Perhaps TRUE (and maybe "top"?) should look back through the stack until it finds a known location, and

Sorry, I'm not seeing the first problem now: options(show.error.locations = TRUE) works fine. Not sure what I did wrong before. I'm still seeing `traceback()` failing to report the attempt to call nofunction(). I suppose this is because a context is never set up for the failed call. Perhaps findFun3 could set up a fake context so that traceback() adds one more entry? Duncan

I've posted a patch to bugs.r-project.org that fixes the traceback() issue. It's not specific to findFun3; you get the same problem with errors from expressions like 1 + "a" In my testing, I occasionally saw cases where show.error.locations = TRUE didn't work. I'll try to track down a reproducible case, and perhaps a patch to fix it. Duncan Murdoch On