MPS issue job003911

TitleCan't dump stack from assertion handler
Statusclosed
Priorityessential
Assigned userGareth Rees
OrganizationRavenbrook
DescriptionIf 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 [1].
AnalysisThe mutator would like to call mps_arena_expose [2], 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.
How foundcustomer
Evidence[1] https://info.ravenbrook.com/mail/2015/02/04/07-28-41/0/
[2] http://www.ravenbrook.com/project/mps/...opic/deprecated.html#c.mps_arena_expose
Created byGareth Rees
Created on2015-02-04 09:24:36
Last modified byGareth Rees
Last modified on2016-09-13 17:32:07
History2015-02-04 GDR Created.

Fixes

Change Effect Date User Description
192365 closed 2016-09-13 17:32:07 Gareth Rees Merge branch/2016-09-06/job004006.