MPS issue job004048

TitleMMQA test cases fail on w3i6mv
Assigned userGareth Rees
Description1. argerr/{17,75,111,141,146,147,148}.c and conerr/44a.c pass null or unaligned pointers to various MPS functions. They expect the test case to abort, but on w3i6mv this doesn't happen. In some cases the test case runs, in others it hits the assertion failure "lock->claims == 0".

2. argerr/43.c passes 0 for the max_size argument to mps_pool_create for mps_class_mv. It expects the assertion failure "maxSize > 0" but got the assertion failure "avgSize > 0". Note that if I run this test case on its own it passes, but if I run it after another test case it fails.

3. function/101.c compiles with warnings:
function/101.c(78) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned long', possible loss of data
function/101.c(108) : warning C4267: 'function' : conversion from 'size_t' to 'unsigned long', possible loss of data

4. function/46.c fails with the assertion "survived <= stats->condemned" -- most likely some object is failing to be accounted as condemned -- see change 191101 [1] for a previous case where this happened.

5. function/76.c fails with the assertion "shield->inside".

6. function/153.c isn't compiled correctly because the command line includes parentheses.

7. function/224.c failed the assertion "AddrIsAligned(old, pool->alignment)"
AnalysisFailure (2) seems to be a bug in the MSVC incremental linker. If we compile and link argerr/42.c and then do the same for argerr/43.c, MSVC doesn't reliably update the executable with the new object code. These two source files are very similar, and the two tests can be compiled and run in under 1 second, which suggests that the incremental linker is using some kind of unreliable heuristic (e.g. timestamp plus length plus a few bytes) to decide whether to replace the object code. Reported to Microsoft as issue 3104624 [2]. Worked around in change 192467 [7].

Failure (3) easily fixed in change 192462 [6].

Failure (4) is a bug in the MPS (and not in the test suite) so it is recorded separately as job004049 and fixed in change 192387 [3].

Failure (5) is a bug in the MPS (and not in the test suite) so it is recorded separately as job004054 and fixed in change 192473 [8].

Failure (6) just needs the parentheses removing from the paramateres; fixed in change 192457 [5].

In (7) the test case hard-codes the alignment as 8, but on w3i6mv it is 16; fixed in change 192456 [4] by using MPS_PF_ALIGN.
How foundautomated_test
Created byGareth Rees
Created on2016-09-14 10:15:32
Last modified byGareth Rees
Last modified on2016-10-12 15:47:10
History2016-09-14 GDR Created.


Change Effect Date User Description
192503 closed 2016-10-12 15:47:10 Gareth Rees Some MMQA test cases assert on Windows but abort with a segmentation fault on OS X. Use new test outcome assert_or_abort so that these pass on all platforms.
192467 open 2016-09-26 18:21:01 Gareth Rees Differentiate argerr/42.c and argerr/43.c so that the MSVC incremental linker reliably updates the executable when we compile one and then the other.
192462 open 2016-09-26 16:59:35 Gareth Rees Avoid "conversion from 'size_t' to 'unsigned long', possible loss of data" warnings from Microsoft Visual C.
192457 open 2016-09-26 16:17:38 Gareth Rees Avoid parentheses in parameters so that the test case passes on Windows.
192456 open 2016-09-26 16:13:39 Gareth Rees Platform alignment is 16 on w3i6mv, so use MPS_PF_ALIGN to avoid alignment failure.