Denis Golovan wrote: > jit.opt.start("maxmcode=10240", "maxtrace=3000", "maxside=400", > "maxsnap=3000", "maxirconst=2000", > "hotloop=5", "hotexit=20", "instunroll=25", > "loopunroll=100", "callunroll=25") That looks a bit excessive. Though it should still work. It's hard to give advice without seeing the actual code in question. But the above looks more like the result of a raging battle against the JIT compiler, not like a reasonable choice of parameters. I wonder whether your problems couldn't be solved better by working around these issues in your code. E.g. using branch-free idioms, manually unrolling loops with a low iteration count or on-the-fly code generation from templates. > jit.opt.start("-abc") -- without this one if happens really often Well, FFI accesses are not bounds-checked, anyway. So disabling ABC elimination does nothing for those loops. The problem must be somewhere else. > Could you suggest something? Just from your description alone it's not possible to suggest anything you could do to analyze this further. I guess you really need to distill it into a short, complete and isolated test case. That said: out-of-bounds FFI write accesses and unanchored FFI cdata objects are very common causes for intermittent crashes and various strange symptoms. You should double-check the code for that. If the problems cease when you use collectgarbage("stop") then you most certainly have an unanchored FFI cdata object. --Mike