similar to: R 3.4 and mclapply assertion failure - is this a bug?

Dear all,? I am not sure if this is a bug, so I prefer to post it here before filing. After upgrading to 3.4 I encounter the following message with mclapply: Assertion failure at kmp_runtime.cpp(6480): __kmp_thread_pool == __null.OMP: Error #13: Assertion failure at kmp_runtime.cpp(6480).OMP: Hint: Please submit a bug report with this message, compile and run commands used, and machine

Full_Name: Yan Alperovych Version: R 2.10.1, GUI 1.31 OS: Mac OS 10.6.2 Submission from: (NULL) (139.165.27.244) Hello everyone, I am not sure if I am at the right place to put this question, so don't hesitate to redirect me to the correct mailing list. My question is about the editor window under the R GUI on Mac OS 10.6.2. Before the upgrade to R 2.10.1 with GUI 1.31, I was able to call

Dear members, I am using arfima in an mclapply construction (from the parallel package): Browse[2]> LYG <- mclapply(LYGH, FUN = arfima, mc.cores = detectCores()) ^C Browse[2]> LYG <- mclapply(LYGH[1:10], FUN = arfima, mc.cores = detectCores()) ^C Browse[2]> LYG <- mclapply(LYGH[1:2], FUN = arfima, mc.cores = detectCores()) ^C You can see that I am

Dear parallel users and developers, I might have encountered a bug in the function 'mclapply' of package 'parallel'. I construct a matrix using the same input data and code with a single difference: Once I use mclapply and the other time lapply. Shockingly the result is NOT the same. To evaluate please unpack the attached archive and execute Rscript mclapply_test.R I put the

Dear Jeff, There was a problem in LYGH and lapply threw an error, but mclapply got stuck in an infinite loop. The doc for mclapply says that mclapply runs under try() with silent = TRUE. So that means mclapply should run properly, i.e output a try class object and exit. But it didn't. Can you shed some light on why this happened? THanking you, Yours sincerely, AKSHAY M

Hello, I have been having issues using parallel::mclapply in a memory-efficient way and would like some guidance. I am using a 40 core machine with 96 GB of RAM. I've tried to run mclapply with 20, 30, and 40 mc.cores and it has practically brought the machine to a standstill each time to the point where I do a hard reset. When running mclapply with 10 mc.cores, I can see that each process

Regarding the following code, warning(sprintf(ngettext(has.errors, "scheduled core %s encountered error in user code, all values of the job will be affected", "scheduled cores %s encountered errors in user code, all values of the jobs will be affected"), paste(has.errors, collapse = ", ")), domain = NA) has.errors is a vector whose elements are the

The attached diff address the following issues in mclapply mclapply coerces non-lists or objects (S3 or S4) to lists, but a list may not be an efficient representation and is not required if the object implements length, [, and [[ methods (lapply must also work on the object, either through coercion to a list at the 'inner.do' level or through other means, e.g., promoting lapply to a

dear R experts---I am looking at a fairly uninformative error in my program: Error in mclapply(1:nrow(opts), solveme) : (converted from warning) all scheduled cores encountered errors in user code the doc on ?mclapply tells me that In addition, each process is running the job inside try(..., silent=TRUE) so if error occur they will be stored as try-error objects in the list. I looked up

On Wed, 17 May 2023 13:55:59 +0000 akshay kulkarni <akshay_e4 at hotmail.com> wrote: > So that means mclapply should run properly, i.e output a try class > object and exit. But it didn't. Can you shed some light on why this > happened? What's your sessionInfo()? Are you using a GUI frontend? mclapply() relies on the fork() system call, which is tricky to get right in a

Hello, Consider this: 1) library(parallel) res <- mclapply(1:2, stop) #Warning message: #In mclapply(1:2, stop) : # all scheduled cores encountered errors in user code is(res[[1]], 'try-error') #[1] FALSE 2) library(parallel) res <- mclapply(1:2, stop, mc.preschedule=FALSE) #Warning message: #In mclapply(1:2, stop, mc.preschedule = FALSE) : # 2 function calls resulted in an

Dear all. I am using the mclapply function to split my code to the many cores my system has. It seems that is working fine. This is the parallel version of lcapply. The only problem that I seem to have is that the printf cannot print messages. The ideal to me is to have fro my function an output of the form Shadowlist<-mclapply(1:dimz, function(i) { print(sprintf('Creating the

Hey folks, Is there any way to exit an mclapply early on error? For example, in the following mclapply loop, I have to wait for all the processes to finish before the error is returned. ``` mclapply(X = 1:12, FUN = function(x) {Sys.sleep(0.1); if(x == 4) stop()}, mc.cores = 4, mc.preschedule = F) ``` When there are many calculations in FUN, it takes a long time before the error is returned.

Hi, there seem to be some (small) bugs in the mclapply function in parallel. I discovered this in the current R release version, and I checked that it is still present in R-devel. I think it only occurs in the part of the code corresponding to argument option mc.preschedule = FALSE. Here are two examples: a) library(parallel) mclapply(list(), identity, mc.preschedule=FALSE) Error in

I've been using mclapply and have encountered situations where it gives errors or returns incorrect results. Here's a minimal example, which gives the error on R 2.15.2 on Mac and Linux: library(parallel) f <- function(x) NULL mclapply(1, f, mc.preschedule = FALSE, mc.cores = 1) # Error in sum(sapply(res, inherits, "try-error")) : # invalid 'type' (list) of argument

Hi Thibault, mclapply has been designed to signal an error in two ways. User code errors are returned as special objects (of class "try-error") in the respective element of the result list. All other errors (including a process killed) are returned as NULL in the respective elements of the result list. To detect these errors reliably, one needs to implement FUN so that it never

I'm running r 2. on a mac running 10.6.4 and a dual-core macbook pro. I'm having a funny time with multicore. When I run it with 2 cores, mclapply, R borks with the following error. The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()

Well it's only a leak if you don't get the memory back after it returns, right? Anyway, one (untested by me) possibility is the copying of memory pages when the garbage collector touches objects, as pointed out by Radford Neal here: http://r.789695.n4.nabble.com/Re-R-devel-Digest-Vol-149-Issue-22-td4710367.html If so, I don't think this would be easily avoidable, but there may be

On Fri, 12 Apr 2019 at 21:32, Travers Ching <traversc at gmail.com> wrote: > > Just throwing my two cents in: > > I think removing/deprecating fork would be a bad idea for two reasons: > > 1) There are no performant alternatives "Performant"... in terms of what. If the cost of copying the data predominates over the computation time, maybe you didn't need

On Sat, 13 Apr 2019 at 18:41, Simon Urbanek <simon.urbanek at r-project.org> wrote: > > Sure, but that a completely bogus argument because in that case it would fail even more spectacularly with any other method like PSOCK because you would *have to* allocate n times as much memory so unlike mclapply it is guaranteed to fail. With mclapply it is simply much more efficient as it will