You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
makeCSR() (the pointer variant) accesses memory past the end of the pos array. This array is passed in by the application, and isn't necessarily padded up in a way that makes this safe. This was causing segfaults for us on Summit, though I no longer have a perfect reproducer for that. Maybe the end of the buffer was perfectly page-aligned and hit the end of the memory map?
Even without the segfaults, we can see these warnings from valgrind that demonstrate the problem:
==463332== Invalid read of size 8
==463332== at 0x4B4F0A4: taco::TypedComponentRef::getAsIndex() const (typed_value.cpp:370)
==463332== by 0x4B42DA6: taco::Index::getSize() const (index.cpp:61)
==463332== by 0x402B02: taco::TensorBase taco::makeCSR<double>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<int, std::allocator<int> > const&, int*, int*, double*, taco::Array::Policy) (tensor.h:760)
==463332== by 0x402505: main (test.cpp:43)
==463332== Address 0x5227f6c is 32,764 bytes inside a block of size 32,768 alloc'd
==463332== at 0x483950F: operator new[](unsigned long) (vg_replace_malloc.c:431)
==463332== by 0x4023EB: main (test.cpp:22)
==463332==
==463332== Invalid read of size 8
==463332== at 0x4B4F0A7: taco::TypedComponentRef::getAsIndex() const (typed_value.cpp:370)
==463332== by 0x4B42DA6: taco::Index::getSize() const (index.cpp:61)
==463332== by 0x402B02: taco::TensorBase taco::makeCSR<double>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<int, std::allocator<int> > const&, int*, int*, double*, taco::Array::Policy) (tensor.h:760)
==463332== by 0x402505: main (test.cpp:43)
==463332== Address 0x5227f74 is 4 bytes after a block of size 32,768 alloc'd
==463332== at 0x483950F: operator new[](unsigned long) (vg_replace_malloc.c:431)
==463332== by 0x4023EB: main (test.cpp:22)
getSize() looks up the last element of pos using a via a TypedComponentRef
The TypedComponentRef reads a 128-bit chunk of memory into a union type (*ptr)
The TypedComponent base class then extracts and returns the 32 bits it wants from the copied data in the union type.
The compiler is splitting up the 128-bit read into two 64-bit reads, which is what valgrind is complaining about. The first 64-bit read is reading 32 bits of valid data and 32 bits of invalid data ("32,764 bytes inside a block of size 32,768"); the second read is completely invalid ("4 bytes after a block of size 32,768 alloc'd").
I think the memory accesses could be cleaned up by passing a pointer into TypedComponent::getAsIndex and changing mem.int32Value to mem->int32Value, but I don't know what impact that change would have on everything else.
Here is the reproducer I used to get the valgrind errors listed above.
The text was updated successfully, but these errors were encountered:
makeCSR() (the pointer variant) accesses memory past the end of the
posarray. This array is passed in by the application, and isn't necessarily padded up in a way that makes this safe. This was causing segfaults for us on Summit, though I no longer have a perfect reproducer for that. Maybe the end of the buffer was perfectly page-aligned and hit the end of the memory map?Even without the segfaults, we can see these warnings from valgrind that demonstrate the problem:
What is happening is this:
makeCSR()makeCSR()callsindex::getSize()getSize()looks up the last element ofposusing a via aTypedComponentRefTypedComponentRefreads a 128-bit chunk of memory into a union type (*ptr)TypedComponentbase class then extracts and returns the 32 bits it wants from the copied data in the union type.The compiler is splitting up the 128-bit read into two 64-bit reads, which is what valgrind is complaining about. The first 64-bit read is reading 32 bits of valid data and 32 bits of invalid data ("32,764 bytes inside a block of size 32,768"); the second read is completely invalid ("4 bytes after a block of size 32,768 alloc'd").
I think the memory accesses could be cleaned up by passing a pointer into
TypedComponent::getAsIndexand changingmem.int32Valuetomem->int32Value, but I don't know what impact that change would have on everything else.Here is the reproducer I used to get the valgrind errors listed above.
The text was updated successfully, but these errors were encountered: