----- Original Message ----- > From: "Jan de Mooij" <[email protected]> > To: "Bill McCloskey" <[email protected]> > Cc: "Benjamin Smedberg" <[email protected]>, "JS Internals list" > <[email protected]> > Sent: Thursday, February 27, 2014 10:56:22 AM > Subject: Re: [JS-internals] Memory poisoning and other ways to make stability > issues more reproducible > > A few weeks ago I looked at a bunch of minidumps of JIT crashes (we > save some code around the instruction pointer and Ted wrote a tool [0] > to extract it from the dump and pass it to objdump). > > Most of these crashes were either obvious memory corruption (for > instance, a typical instruction sequence with 4 corrupt bytes in the > middle), invalid instruction pointer or valid JIT code but accessing a > bogus (object) pointer, suggesting a problem elsewhere.
I remember that in JaegerMonkey we had code to mark JIT pages non-writable. I don't think we ever enabled it in release builds because it was pretty expensive. Should we consider write protection for nightly and aurora just to see if we can track down this sort of memory corruption? I don't know how hard this would be. I remember that the main difficulty in JM was with ICs. However, don't we already do some memory protection of JIT pages for the operation callback? Could we reuse some of that code? -Bill _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
