- removed comment
Memory alignment in CarpetLib failing
Issue #1339
closed
This is happening on a 32bit Debian stable (squeeze) virtual machine (Virtualbox) that I use to test the new users instructions.
Running the QuasiLocalMeasures qlm-ks-boosted test (and other see attachments), I get:
/home/cactus/Cactus/configs/sim/build/CarpetLib/mem.cc:130: mem<T>::mem(size_t, size_t, T*, size_t) [with T = std::complex<double>]: Assertion `size_t(storage_) >= size_t(storage_base_ ) and size_t(storage_) <= size_t(storage_base_ + max_padding)'
Keyword:
Comments (9)
-
-
reporter
- removed comment
It uses the option list simfactory/mdb/optionlists/debian.cfg which does not set VECTORISE (and the default is off, yes) so no VECTORISATION, yes. Is there any files/information/tests I can do to help debug this? I understand that me I am essentially just saying "this does not work" right now but am not sure how to provide a test for it. It might not even be 32bit specific after all.
-
- removed comment
I am testing a patch.
FYI:
$ git diff diff --git a/Carpet/CarpetLib/src/mem.cc b/Carpet/CarpetLib/src/mem.cc index 89d8fb2..0a5f369 100644 --- a/Carpet/CarpetLib/src/mem.cc +++ b/Carpet/CarpetLib/src/mem.cc @@ -105,6 +105,7 @@ mem (size_t const vectorlength, size_t const nelems, size_t const max_cache_linesize = get_max_cache_linesize(); size_t const vector_size = CCTK_REAL_VEC_SIZE * sizeof(T); size_t const alignment = align_up(max_cache_linesize, vector_size); + assert(alignment >= 1); // Safety check assert(alignment <= 1024); // Assume optimistically that operator new returns well-aligned @@ -123,7 +124,8 @@ mem (size_t const vectorlength, size_t const nelems, } else { allocate_with_alignment: // Operator new needs manual alignment - size_t const max_padding = alignment / sizeof(T) - 1; + size_t const max_padding = div_up(alignment, sizeof(T)) - 1; + assert((ptrdiff_t)max_padding >= 0); storage_base_ = new T [vectorlength * nelems + max_padding]; storage_ = (T*) (size_t(storage_base_ + max_padding) & ~(alignment-1)); assert(size_t(storage_) >= size_t(storage_base_ ) and(This corrects a rounding error, and adds more safety checks.)
-
reporter
- removed comment
Unfortunately this does not seem to fix the problem. The issue still remains. I added some printfs to the code to show the values of the variables. Attached please find the test log output and the diff of the source code.
-
- removed comment
New patch:
diff --git a/Carpet/CarpetLib/src/mem.cc b/Carpet/CarpetLib/src/mem.cc index 89d8fb2..be28d20 100644 --- a/Carpet/CarpetLib/src/mem.cc +++ b/Carpet/CarpetLib/src/mem.cc @@ -105,6 +105,7 @@ mem (size_t const vectorlength, size_t const nelems, size_t const max_cache_linesize = get_max_cache_linesize(); size_t const vector_size = CCTK_REAL_VEC_SIZE * sizeof(T); size_t const alignment = align_up(max_cache_linesize, vector_size); + assert(alignment >= 1); // Safety check assert(alignment <= 1024); // Assume optimistically that operator new returns well-aligned @@ -123,7 +124,8 @@ mem (size_t const vectorlength, size_t const nelems, } else { allocate_with_alignment: // Operator new needs manual alignment - size_t const max_padding = alignment / sizeof(T) - 1; + size_t const max_padding = div_up(alignment, sizeof(T)); + assert(ptrdiff_t(max_padding) >= 0); storage_base_ = new T [vectorlength * nelems + max_padding]; storage_ = (T*) (size_t(storage_base_ + max_padding) & ~(alignment-1)); assert(size_t(storage_) >= size_t(storage_base_ ) andOperator new's alignment may be less than the type's size (if a type requires alignment less than its size, such as e.g. complex numbers). Since we assume that a type's alignment is at least its size, we need to request more storage.
-
reporter
- changed status to open
- removed comment
This seems to work. No more test failures. Please apply. Thank you, Erik!
-
reporter
- changed status to open
- removed comment
-
reporter
- changed status to resolved
- removed comment
Applied as commit 9b4e5841e2f30bded4cfed65e37c0ff2393250e8 of Carpet.
-
reporter
- changed status to closed
- edited description
- Log in to comment
I assume this was with vectorisation disabled?