--jobs > 1 raises Bundler::GemspecError on Rubinius #3269
Comments
Can you update to the latest rubygems version and try again? |
😦 |
@jc00ke I am not asking for the bundler version but for the rubygems version, can you upgrade it to the latest one? Also please give output of
|
Ah, sorry, missed that. Same thing though
|
This is strange, I ran bundle install on same Gemfile with JRuby and I didn't see the errors (while they do occur with Rubinius). Both JRuby and Rubinius use the same code in Bundler for parallel jobs, so it seems like the problem is somewhere else. |
@brixen FYI |
I have same problem. |
Since I can't reproduce this on JRuby, which also lacks a GIL, I'm not sure what to do. Are we missing a race condition? Does JRuby have some lock that isn't global but protects against this problem? Totally open to input here, but since I'm personally unfamiliar with Rubinius, I have no idea how to even try to fix this. |
I've seen other issues that suggest it's something to do with |
I've identified and fixed one issue involved here: fix: rubinius/rubinius@7772d05 and specs: rubinius/rubinius@5be264f Troubleshooting this was made significantly harder by code like this in Bundler: https://github.com/bundler/bundler/blob/master/lib/bundler/rubygems_integration.rb#L176-L177 There's no good reason to write code like this, so please consider not doing so. At the very least, included the original exception kind and message somewhere. There is very likely still a race condition somewhere here or we would not be seeing different behavior with A couple other points:
I'm not trying to lecture anyone, but it's frustrating to constantly hear things like, "It works on MRI." or "I'm unfamiliar with Rubinius." We're trying to make Ruby better. If people want to have a better Ruby, then we need people to do the bare minimum to help look at issues. Threading bugs are not terribly scary, but they may look different superficially. Underneath, it's the same debugging we all do every time a program doesn't behave as expected. |
Thanks for letting us know! Because the In the bigger scheme of things, I am of course happy to dig in to debugging things myself when I have time to do so. Since it does work on MRI and JRuby, and I am unfamiliar with Rubinius, it takes more time to work on this sort of bug than most other open issues. I'm especially short on time for that at the moment, which is why I asked if anyone else had ideas. Thanks again for your work on this. |
@indirect I've released 2.4.1, which appears to run with --jobs > 1 correctly. I still don't know what the race was that would result in the constant being an unresolved autoload instance in the concurrent case. Perhaps the race is benign and only resulted in different orderings of loading a particular constant. As you can see from this gist, the autoload issue was hit while somewhere inside Psych https://gist.github.com/brixen/a5971cc930abd2ace163. I'm going to ask Travis to re-enable --jobs for Rubinius and see if we observe any other issue. I think the behavior we have observed is that a race exists. I don't know where it is. I don't know that it will result in pathological execution. That said, I'll leave it up to you whether to close this ticket or not. |
I'll assume that no news is good news and that there haven't been further issues after re-enabling |
And, after I updated calagator to use Bundler 1.7.7 I'm still seeing the same errors.
Some gems start to install, then some fail.
I decided to delete my
Gemfile.lock
and regen it withrbx
. Check out the failures below:--jobs=1
worked locally thoughHopefully some of this helps. I'll try to find some time to remove all of my bundler gem caches per the
ISSUES
doc and verify the errors above. Will also verify on1.7.7
.The text was updated successfully, but these errors were encountered: