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
New MacOS R v3.4.0 CRAN binary support for OpenMP: error with mclapply #2137
Comments
You mention in the r-devel thread that
I may be misunderstanding how exactly this should be done but the following trivial example produces the same errors for me despite
|
@RoyalTS Thanks for this report. Is there any chance you tried this in an R session that had been doing other Please also set these environment variables in the command window before starting R. When you run your R example, diagnostic messages should be printed by Intel's OpenMP library / KMP. Please paste the output to this issue.
|
I'm having trouble reproducing this one. I've obtained a fresh Mac with MacOS Sierra (10.12.5) with R 3.4.1 and using the CRAN binary version of data.table 1.10.4 for Mac. It all seems fine. I start with a fresh R session and invoke some usage of OpenMP with Here's what to paste into a fresh R session:
Here's the output :
|
I can reproduce this error without using fwrite. However my code used a lot of other functions and packages, I'm not sure if it will be helpful. If you can debug the environment instead of source code, maybe it's still useful. Basically I have a package that depend on My guess is that my code used data.table in some process, then created multiple cores with |
These parallel bugs are tricky. At one time I though I can produce/avoid the bug with slight different code repeatably, then the bug just disappeared all together with clean R sessions. |
@mattdowle When I installed |
Looks like this one is ongoing on MacOS with |
This was reported on r-devel :
https://stat.ethz.ch/pipermail/r-devel/2017-May/074178.html
First I knew that CRAN binaries for MacOS now support OpenMP. Great news!
Either the fork catch isn't working in that environment for some reason, the use case is different to the tests somehow or the fork catch is working but something somewhere is asserting its surprise at being single threaded.
The text was updated successfully, but these errors were encountered: