[Boost-bugs] [Boost C++ Libraries] #10616: tagged_ptr assumes zero leading bits

Subject: [Boost-bugs] [Boost C++ Libraries] #10616: tagged_ptr assumes zero leading bits
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2014-10-05 16:32:01

#10616: tagged_ptr assumes zero leading bits
 Reporter: nyh@… | Type: Bugs
   Status: new | Milestone: To Be Determined
Component: None | Version: Boost 1.54.0
 Severity: Problem | Keywords:
 I've noticed that boost::lockfree::queue does not work on the OSv
 operating system, crashing when used.

 After some investigation, I discovered the problem: lockfree::queue uses
 tagged_ptr, and that, when compiled on x86_64, uses
 tagged_ptr_ptrcompression which assumes that pointers always start with 16
 zero bits.

 The thing is - the x86_64 standard does *not* guarantee that pointers must
 start with all zero bits. It just guarantees that pointers are so-called
 "canonical", meaning that the first 16 (usually) bits are either all 0, or
 all 1. But they *can* be all 1-s, and indeed in OSv, malloc()ed memory has
 addresses starting with all 1s. By the way, in Linux, kernel-space memory
 (as opposed to user-space memory) also has such addresses.

 But tagged_ptr::extract_ptr() assumes that the leading bits of pointers
 are always zero - which happens to be true on Linux's user-space memory
 but is not generally guaranteed by x86_64 (and isn't true on OSv).

 I'm not sure what to suggest as a fix. One not-really-safe-but-will-
 probably-work-in-practice option is to choose to fill the pointer with 0
 or 1 bits depending on the 47th bit. Another not-quite-foolproof option is
 to assume that in one program all pointers will start with the same prefix
 (all 0 or all 1), so calculate this prefix once at runtime and then use it
 every time.

Ticket URL: <https://svn.boost.org/trac/boost/ticket/10616>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:17 UTC