CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger

FIXED IN:
tiger

INTEGRATED IN:
tiger
tiger-b10


                                     

EVALUATION

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).

###@###.### 2003-06-16