Getting a segv after a while #153
Comments
That is the most likely culprit. The V8 GC should only happen in threads locked by V8, but its possible that there is a bug there. Is this the suite for handlebars? |
Nope... it's the suite for my html5-parser library. It happens when I turn on some of the tests that are not currently running in master. |
This is the same thing I stumbled on in rubinius, where memory regions aren't static; the memory gets corrupted, because the GC's are apparently not in any particular sync. It also explains some occasional crashes on ruby, like this one, when a process has been running for a while. |
@jammi the problem with rubinius is that therubyracer assumes that ruby object's physical address will not change from the time it is allocated to the time it is garbage collected. This is a valid assumption for MRI, but not Rubinius which will move an object around during it's lifespan in order to optimize memory usage. This is a known issue with therubyracer on rubinius and requires some significant rework of its internals. When I orignally wrote it, I was only targeting MRI and only nominally aware of garbage collection internals. The issue here, when I have time to track it down, should be solvable easily, whereas Rubinius support will probably not come until at least 0.12 therubyracer takes great care to make sure that GC in both systems takes place in an orderly fashion; enqueueing js objects when their ruby peers are garbage collected, and then consuming that queue only during V8 GC. |
@jammi master now supports rubinius. It's still not quite read for release, but should be far more stable. |
@wycats Is this a problem if you use therubyracer from master? You'll need the following adapter on your require function to get the specs to run, but they seemed to do ok for me. #ignore `this` object
def js_require.methodcall(this, *args)
call *args
end |
I'm running tests through TRR, and when I have a particularly large suite, I get the following segv. The specific test where it happens is inconsistent, and doesn't happen when I run the test isolated. Maybe it's a bad GC interaction?
The text was updated successfully, but these errors were encountered: