Reproducible on Unisys' MP systems only. We can't reproduce it on the
2-way systems we have.
Unisys's report seems to imply that the stack-allocated variables lpProcessAffinityMask and lpSystemAffinityMask,
when they're declared to be DWORD's, have been allocated by the C++ compiler
on 4-byte boundaries, thus provoking a segv when GetProcessAffinityMask
tries to write them as if they were UINT_PTR's, which must be aligned
on an 8-byte boundary. But if this were so, *every* call to
GetProcessAffinityMask would provoke a segv. So we ought to be seeing
this problem on our machines, but we don't. I suspect we're running an
OS that silently fixes up misaligned data accesses, and Unisys isn't.
Also, it looks like our implementation of os::active_processor_count is
flawed in a further way, since GetProcessAffinityMask returns bit vectors
that can be up to os::processor_count long, whereas a DWORD is limited to
32 bits and a UINT_PTR 64. The fix is to only call GetProcessAffinityMask
if the total processor count is <= bitsize(UINT_PTR).