Segfault w/ Ruby 1.9.2-p180 and the uglifier gem #79
Comments
|
Bizarre place for a crash. I'll have a look. |
|
Same in ubuntu 11.04 x86 |
|
The problem appears to be a threading issue, and probably the same one that @anildigital encountered in #73 Specifically, the thread that initializes v8 is different than the one handling the request. My guess is that v8 uses a thread local to store its global data, and so it freaks out when it can't find it. For right now, you can work around this issue by adding this middleware to your stack to lock V8. This shouldn't be a problem since assets are only generated on the fly during development mode. Also, this is not a problem for forking servers like passenger and unicorn. It's been on my list to do more intelligent locking, so that these type of workarounds aren't necessary, but it definitely needs some thought to get it right. |
|
Interesting. Explains why it doesn't happen from a single process rake task. |
|
I think that's the best place for it. I'd thought about putting the lock into the rubyracer itself, but it would need to be done carefully since you need to unlock v8 whenever you call back out from JavaScript into embedded Ruby code. Since execjs does not embed any Ruby code (that's a valid assumption, right?), then it would be perfectly safe to put a lock around it. It might be a little bit finicky, since according to the v8 list if you use locking anywhere, then you need to use it everywhere, but I don't see any reason why it couldn't be made to work. |
|
@josh BTW, I can submit a pull request for this if you'd like. |
|
@cowboyd how does this look? sstephenson/execjs@a48bc7c |
|
v8 locking has been integrated into ExecJS 1.1.2 |
|
I'm afraid it doesn't fix the issue. If I turn off https://gist.github.com/1011718 middleware, error comes back even with execjs 1.1.2: https://gist.github.com/1017379 |
|
This appears to be a different error, is this a consistent and reproducible or intermittent? |
|
Crap. What's happening is that therubyracer garbage collection routines are not locking V8, and so when your ruby process stops to do GC and free up some old JavaScript objects, it crashes. By putting this in the middleware, you greatly reduce the chance that the ruby GC will run in code that doesn't hold the V8 lock, but you still are open to a crash happening if GC runs before you enter the locking middleware. I'd hoped to put off a comprehensive locking solution until 0.9.1 or 0.9.2, but maybe we can fit it into 0.9.0 |
|
This will be going into 0.9.1, for a write up of the issue as well as an explanation of the timing: http://blog.thefrontside.net/2011/06/13/therubyracer-isnt-threadsafe-yet/ |
|
I'm so glad you reopened. I've been trying to get a handle on these segfaults, assuming that it must be something else since execjs-1.1.2 was supposed to fix the problem. It's amazing how the experience of a problem changes when upstream says there's a fix coming. :-) |
|
Ok. therubyracer >= 0.9.1beta1 will not do any V8 operations inside the Ruby GC thread, and so now the locking put in place by ExecJS should actually do the trick. I'd appreciate it if folks could test this out and let me know how things go. For those interested, the patch is here @05e4c5766f66a301238c1da49691c8ef8a037152 |
|
No errors on 0.9.1b1 for now. Using webrick. |
|
Same goes for me, no errors since I upgraded to 0.9.1b1. |
|
1.9.1 is solid, thanks. |
|
Looks like that's a wrap folks. |
|
I'm seeing this issue on 0.9.2 with Ruby 1.9.2. Here's the dump. partial gem list: |
|
What About 0.9.3beta1? |
|
Yes, 0.9.3beta1 fixes it. After I posted that comment I discovered issue #89 and now I understand the autolocking stuff. Thanks! |
Running on Rails 3.1-stable with the uglifier preprocessor turned on:
The text was updated successfully, but these errors were encountered: