|Title||Can't dump stack from assertion handler|
|Assigned user||Gareth Rees|
|Description||If the mutator stores code objects or stack frames in automatically managed memory, then emitting a stack dump requires access to memory that's managed by the MPS. This means that an assertion handler can't dump the stack, even though this would be a very useful thing to be able to do. See .|
|Analysis||The mutator would like to call mps_arena_expose , but it can't from the assertion handler, because assertion handlers are not allowed to call back into the MPS. (See job003908.) Ideas:|
1. The MPS could provide another installable handler that is called after the MPS releases its lock following an assertion failure. The mutator's handler could then call mps_arena_expose before dumping stack. This would at least capture the mutator stack leading up to the assertion even if the MPS stack was omitted.
2. Provide a way for the user to peek at protected memory (a form of soft write barrier). The trouble is that when an assertion handler is called, the MPS data structures are not known to be consistent, so it is not known to be safe to call ShieldExpose and ShieldCover.
3. The MPS could know that it's in an assertion handler (or the mutator could tell it), and so process a barrier hit in a different way: for example, just drop the protection and return without calling ArenaAccess.
4. The MPS could provide a function that drops all memory protection (by iterating over the chunks). Obviously it would not be possible for the MPS to reliably continue afterwards, so we'd have to explain that in big warning letters.
See also job003556, job003951, job004006.
|Created by||Gareth Rees|
|Created on||2015-02-04 09:24:36|
|Last modified by||Gareth Rees|
|Last modified on||2016-09-13 17:32:07|
|History||2015-02-04 GDR Created.|
|192365||closed||2016-09-13 17:32:07||Gareth Rees||Merge branch/2016-09-06/job004006.|