| Title | Epoch number can wrap around on 32-bit platforms |
| Status | open |
| Priority | optional |
| Assigned user | Gareth Rees |
| Organization | Ravenbrook |
| Description | The epoch number is stored in an Epoch, which is a typedef for Size, and on 32-bit platforms (such as Windows) this is a 32-bit number. There are about 2^32 centiseconds in a year, so a long-running application that collects frequently can cause this number to wrap around on a timescale of years. |
| Analysis | We could change Epoch so that it gets 64 bits even on 32-bit Windows (the type needs to be unsigned long long to get 64 bits in Visual Studio). The only places where an epoch number is stored is in the ArenaStruct [1] and in mps_ld_s [2] (where mps_word_t is used), so the memory consequences are not severe (an additional 4 bytes for each client structure containing an mps_ld_s). When the epoch number overflows, what will actually go wrong? * LDAge: fine. * LDIsStaleAny: the assertion AVER(ld->_epoch <= arena->epoch) will go off. But if that is ignored, the function seems OK: the subtraction arena->epoch - ld->_epoch will wrap around correctly. * LDMerge: two assertions will go off. And if those are ignored, it can pick the wrong epoch for the merged LD (it uses the test "from->_epoch < ld->_epoch", but this will no longer be reliable). Incorrect merges might happen less often if the test were changed to "arena->epoch - from->_epoch > arena->epoch - ld->_epoch". |
| How found | inspection |
| Evidence | [1] <//info.ravenbrook.com/project/mps/master/code/mpmst.h>[2] < //info.ravenbrook.com/project/mps/master/code/mps.h> |
| Created by | Gareth Rees |
| Created on | 2014-03-07 09:55:05 |
| Last modified by | Gareth Rees |
| Last modified on | 2014-10-25 23:14:47 |
| History | 2014-03-07 GDR Created. |