@Vyacheslav Egorov
Yes. Your hint was absolutely correct.
Those checks immediately triggered.
And yes, decreasing maxtrace, maxsnap solved the problem.
@Mike and others
Is it possible to increase nsnap* and related variables width?
It looks like a pretty simple fix which does not have any negative side effects.
I mean I bumped mapofs,nsnap,nsnapmap and their casts to uint32_t and
that's it. Am I missing something?
2016-11-30 14:27 GMT+02:00 Vyacheslav Egorov <dmarc-noreply@xxxxxxxxxxxxx>:
Yeah, given that you increased both snapshot size and a trace size you are
most certainly just overflowing something in the snapshot implementation -
which does not guard against it.
On Wed, Nov 30, 2016 at 11:55 AM Denis Golovan <denis.golovan@xxxxxxxxx>
wrote:
I use the following options:
jit.opt.start("maxmcode=10240", "maxtrace=3000", "maxside=400",
"maxsnap=3000", "maxirconst=2000",
"hotloop=5", "hotexit=20", "instunroll=25",
"loopunroll=100", "callunroll=25")
Thanks, I'll try your suggestion and come back.
2016-11-30 12:34 GMT+02:00 Vyacheslav Egorov
<dmarc-noreply@xxxxxxxxxxxxx>:
Are you running with default JIT parameters - or did you tweak any?
I have seen this sort of thing happen when things overflow uint16_t.
You can try running with:
if (((MSize)(uint16_t)(snap->mapofs + m)) != (snap->mapofs + m))
abort();
to check if this is the case.