-
Notifications
You must be signed in to change notification settings - Fork 991
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
loading data.table causes mclapply() to hang on MacOS #2418
Comments
Thanks for the report. Item 4 from NEWS for 1.10.4-1 :
In dev I improved that same item but neglected to backport that news items change to the CRAN patch. From dev NEWS file :
However, in your case, you haven't even used data.table before forking. So that is a new aspect that hasn't been reported before. Is your reproducible example strictly correct in that those 3 lines are literally all that occurs in a fresh R session? i.e. no usage of data.table between loading it and calling Have you installing the CRAN mac binary, or from source? It appears to be critical on MacOS, with respect to this Can you compile from source using the MacOS instructions and does that help? Maybe that links to the proper OpenMP library locally for you, or something like that. Some people have not followed the instructions precisely enough, so they have to be followed precisely on MacOS. Does Item 1 from NEWS from 1.10.4-2 I doubt is related, but I'll mention it for completeness :
Here are related issues : I'm basically struggling with MacOS. If there is anyone listening from Apple and/or Intel who can support their products, that would be great. I struggle to see how it's a data.table issue really. I've tried everything I can think of to work around it and document it in NEWS. Help and suggestions much appreciated. |
Yes, the simple script with only
This is on the Bioconductor build machines. I believe this is a simple binary installation, but will confirm. We have
and
So presumably linking to libomp.
|
Thanks for this. Yes those On the hang with the mere 3 lines though, is it possible Intel's OpenMP library creates its threads upon being linked or initialized? If so, that might explain that. Otherwise, I'm at a loss on that. Further, I don't know how the OpenMP abilities of I just came across the source code for the Intel OpenMP runtime. I don't know what this project is because I thought Intel's library was closed source. But maybe it's possible to compile against it and debug it. https://www.openmprtl.org/ Probably easier just to compile locally first and see if that works, or use GNU library.
Maybe this is needed with the CRAN package binary: http://macappstore.org/libiomp/ |
Intel's library is printing :
Could someone with the problem on MacOS file an issue with Intel please? |
Hi, I originally reported the issue with the BiocParallel repository as I encountered the issue while using functions from that package. They've narrowed the issue to mclapply being called while data.table is loaded. I followed the directions here to install the latest version of data.table on my MacOS, but still encountered the issue. Interestingly, a colleague had the latest version of data.table installed on his Mac and did not have any issues. However, he did not have OpenMP installed on his system. I was able to fix the problem by rolling back to data.table 1.10.2. |
@asenabouth Can you raise a support request with Intel please (see my comment above)? It appears to be a problem with their library. Alternatively, perhaps someone from Apple can help. Are you able to get their support at all? I'm not convinced that installing from source does not solve it. Can you show the commands and output please. Is anyone else unable to use |
I will file a support request with Intel. As for installing from source, here is the installation and subsequent test:
And here's the session info:
EDIT:
|
I've posted the following https://software.intel.com/en-us/forums/intel-c-compiler/topic/746943 It's probably in the wrong place and I'll probably get flamed but hopefully it will get the ball rolling. @mattdowle let me know if there are things you would like me to add/do |
Wanted to confirm that I reproduced the same error as @asenabouth and that reinstall 1.10.4 from source fixed the problem. sessionInfo:
|
Just logging some details on my machine
produces
with
|
Interestingly,
produces
I'm going to see if this is related |
I also followed the instructions at https://github.com/Rdatatable/data.table/wiki/Installation and the problem still occurs.... EDIT: |
Thanks everybody. It's interesting that 1.10.4 appears to work ok but 1.10.4-2 does not. It appears to crash as soon as the fork is called. The attempt I mentioned in NEWS was in that area. First, what didn't change. Upon loading data.table,
so when
before (in 1.10.4), it didn't used to call
All I can think is that call to
|
@joethorley That's odd. You get |
@joethorley Do you have gettext installed? Turns out I didn't. I was able to compile the package correctly on my system once that was done. |
@mattdowle no the
occurred. |
My Makevars is
My sessionInfo()
and my R session
|
|
@asenabouth I do have gettext installed and I was able to compile the package correctly once I follow the instructions. My post was a little unclear so I have edited. |
|
Installing 1.10.4.2 from CRAN, either source or binary, results in the mclapply hang. Installing github.com/Rdatatable/data.table@master from source still produced the original mclapply hang. Installing this modified version of the current master
or this version
clears the hang for me. The R we use (installed as a binary from CRAN) is the 3.4.2 release
Setting the environment variable OMP_NUM_THREADS=2 did not change the outcome. |
I can confirm commenting out
|
Thanks everyone. Made the fix in dev and is passing. @joethorley Would you or someone else confirm that latest 1.10.5 is ok now. I'll start preparing 1.10.4-3 to go to CRAN. |
I can confirm it is fixed.
|
Many thanks @joethorley! Submitted to 1.10.4-3 to CRAN and all being well, it will take a few days for the magic of CRAN to run its course.
Closing for now. Please reopen or open a new issue if there's a problem with 1.10.4-3. |
@mattdowle: it looks like v1.10.4-2 is still the version being distributed by CRAN. Is v1.10.4-3 still waiting in the CRAN submission queue, or did something else go wrong? (thank you for getting a workaround out for this issue so quickly; it unfortunately appears to be affecting a large number of users on macOS) |
@kevinushey Yes 1.10.4-3 was waiting in the queue (in the 'recheck' status which I don't know what that means, for 6 days). I sent an email to CRAN and it's now released to CRAN. |
maybe I am making something wrong but I still have the issue on my mac.
When installing the cran version from source, I get:
I can provide more details if necessary. |
@davidgohel: Please see this guide for getting the R LLVM toolchain installed locally. http://thecoatlessprofessor.com/programming/openmp-in-r-on-os-x/ Alternatively, I would recommend editing the file at |
@kevinushey OK, I will have a try with the alternative solution. I think I messed something with the first solution. |
Adding this to my
|
@mjsteinbaugh @kevinushey thanks, it worked |
I tried editing the file at |
@ValeriVoev The file at |
Thanks @kevinushey - I finally made it work, installed |
I still see this error randomly 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 configuration info including native compiler and operating system versions. Faster response will be obtained by including all program sources. For information on submitting this issue, please see http://www.intel.com/software/products/support/. And the case is really tricky.
This all seemed to be related to environment changes. Unfortunately I don't have a simple reproducible example now. My code is quite complex and involves a lot of other things. |
Like dracodoc, have the (6480) catch randomly. macOS 10.13.3, R 3.4.3, data.table 1.10.4-3. Just plain R here and too complex code to reproduce. Simple mclapply's at the start of the code work and sometimes make the rest of the code work as well. In my case, adding EDIT: Alas, the execution does not seem to be stable, and though mcmapply starts, it hangs after some time. |
I've just seen these further comments. Please either try dev 1.10.5 or wait for next CRAN release (hopefully soon). If still a problem after that, please raise a new issue. |
I'm still seeing the same problem with dev 1.10.5. New issue created. |
This issue Bioconductor/BiocParallel#67 seems to lead to
hanging, with
The text was updated successfully, but these errors were encountered: