Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LV: Proper alignment of buffers for use with SIMD routines #6

Open
kaixiong opened this issue Apr 11, 2012 · 5 comments
Open

LV: Proper alignment of buffers for use with SIMD routines #6

kaixiong opened this issue Apr 11, 2012 · 5 comments
Milestone

Comments

@kaixiong
Copy link
Member

VisVideo, VisDFT and VisAudio buffers need to be properly aligned in order for SIMD routines to work at maximum efficiency. MMX requires at least 8-byte alignments; SSE/SSE2 and Neon need 16; and finally AVX needs 32.

Neither malloc() nor C++'s new operator will automatically provide such a large alignment. We will have to create a visual_new_aligned() based on _allgned_malloc() on WIndows and memalign() on POSIX. According to some sources, OS X does not have memalign(), but we can count on its malloc() always producing addresses at 16 byte boundaries.

Objects allocated in C++ using new will need a custom allocator and the use of placement new.

Additionally, for buffers holding 2-dimensional data such as VisVIdeo, and where block operations such as blitting are performed row by row, every data row requires a similar alignment. Padding will need to be added to achieve this (while keeping contiguity).

@dsmit
Copy link
Contributor

dsmit commented Apr 11, 2012

Or, do a byte-by-byte head and tail loop around the SIMD stuff that loops till it aligned the data (or went through it), we need this anyway for small data sets.

For example, if a data set only contains 5 bytes, aligned or not, we can't feed it to SSE or AVX. (I wouldn't write stuff in MMX nowadays), the routines we have remain valid of course.

Also: LIBOIL / ORC.

@kaixiong
Copy link
Member Author

We probably don't need SIMD for small data sets. The overhead associated with SIMD state saving/switching, and the fact that there's little data to compute makes the effort not really worth the trouble, I would think. Doing proper alignment is also quite a lot simpler than making routines account for any kind of starting address.

@kaixiong
Copy link
Member Author

Did a few more checks on the Intarwebz; it's basically guaranteed by glibc and VC++ that malloc() returns 8-byte and 16-byte aligned pointers on 32-bit and 64-bit systems respectively.

http://msdn.microsoft.com/en-us/library/ycsb6wwf.aspx
http://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html

@dsmit
Copy link
Contributor

dsmit commented Apr 12, 2012

In regards to small data sets: Indeed no SIMD is needed here, but I don't think that having _small and _large API calls is a bit awkward ;-).

@kaixiong
Copy link
Member Author

Added visual_mem_alloc_aligned() and visual_mem_free_aligned() in bcf3193

hartwork added a commit that referenced this issue Jan 25, 2023
.. by adding the missing virtual destructor to class Hashable.

ASan output was:
> =================================================================
> ==21660==ERROR: AddressSanitizer: new-delete-type-mismatch on 0x603000079d20 in thread T0:
>   object passed to delete has wrong type:
>   size of the allocated type:   32 bytes;
>   size of the deallocated type: 8 bytes.
>     #0 0x7f98137dc2a7 in operator delete(void*, unsigned long) /var/tmp/portage/sys-devel/gcc-11.3.1_p20221223/work/gcc-11-20221223/libsanitizer/asan/asan_new_delete.cpp:172
>     #1 0x7f9802700116 in Hashtable::RemoveAll() [..]/libvisual-plugins/plugins/actor/G-Force/Common/GeneralTools/Hashtable.cpp:202
>     #2 0x7f980270023f in Hashtable::~Hashtable() [..]/libvisual-plugins/plugins/actor/G-Force/Common/GeneralTools/Hashtable.cpp:32
>     #3 0x7f98026dc9d5 in ExpressionDict::~ExpressionDict() ../../../../plugins/actor/G-Force/Common/math/Headers/ExpressionDict.h:20
>     #4 0x7f98026dc9d5 in WaveShape::~WaveShape() ../../../../plugins/actor/G-Force/GForceCommon/Headers/WaveShape.h:11
>     #5 0x7f98026dc9d5 in GForce::~GForce() [..]/libvisual-plugins/plugins/actor/G-Force/GForceCommon/G-Force.cpp:249
>     #6 0x7f980270e7a5 in lv_gforce_cleanup [..]/libvisual-plugins/plugins/actor/G-Force/unix/libvisual/actor_gforce.cpp:140
>     #7 0x7f981367e236 in visual_plugin_unload [..]/libvisual/libvisual/lv_plugin.c:655
>     #8 0x7f9813674563 in actor_dtor [..]/libvisual/libvisual/lv_actor.c:52
>     #9 0x7f98136aa9e8 in visual_object_destroy [..]/libvisual/libvisual/lv_object.c:104
>     #10 0x7f981367c090 in visual_bin_switch_finalize [..]/libvisual/libvisual/lv_bin.c:695
>     #11 0x7f981367c9dd in visual_bin_run [..]/libvisual/libvisual/lv_bin.c:853
>     #12 0x5649c53eeedc in LV::Bin::run() [..]/libvisual/tools/lv-tool/lv-tool.cpp:108
>     #13 0x5649c53eeedc in main [..]/libvisual/tools/lv-tool/lv-tool.cpp:853
>     #14 0x7f981317e209  (/lib64/libc.so.6+0x2a209)
>     #15 0x7f981317e2bb in __libc_start_main (/lib64/libc.so.6+0x2a2bb)
>     #16 0x5649c53f2110 in _start ([..]/INSTALL_PREFIX/bin/lv-tool+0xa110)
>
> 0x603000079d20 is located 0 bytes inside of 32-byte region [0x603000079d20,0x603000079d40)
> allocated by thread T0 here:
>     #0 0x7f98137db247 in operator new(unsigned long) /var/tmp/portage/sys-devel/gcc-11.3.1_p20221223/work/gcc-11-20221223/libsanitizer/asan/asan_new_delete.cpp:99
>     #1 0x7f98026edd5e in ExpressionDict::AddVar(char*, float*) [..]/libvisual-plugins/plugins/actor/G-Force/Common/math/ExpressionDict.cpp:15
>     #2 0x7f98026e9331 in ExpressionDict::AddVar(UtilStr&, float*) [..]/libvisual-plugins/plugins/actor/G-Force/Common/math/Headers/ExpressionDict.h:27
>     #3 0x7f98026e9331 in ExprArray::Compile(ArgList const&, long, ExpressionDict&) [..]/libvisual-plugins/plugins/actor/G-Force/Common/math/ExprArray.cpp:67
>     #4 0x7f98026e0900 in WaveShape::Load(ArgList&, long) [..]/libvisual-plugins/plugins/actor/G-Force/GForceCommon/WaveShape.cpp:76
>     #5 0x7f98026d898d in GForce::loadWaveShape(long, bool) [..]/libvisual-plugins/plugins/actor/G-Force/GForceCommon/G-Force.cpp:1251
>     #6 0x7f98026db109 in GForce::RecordSample(long) [..]/libvisual-plugins/plugins/actor/G-Force/GForceCommon/G-Force.cpp:917
>     #7 0x7f980270ea8e in lv_gforce_render [..]/libvisual-plugins/plugins/actor/G-Force/unix/libvisual/actor_gforce.cpp:264
>     #8 0x7f98136767de in visual_actor_run [..]/libvisual/libvisual/lv_actor.c:777
>     #9 0x7f981367c71a in visual_bin_run [..]/libvisual/libvisual/lv_bin.c:865
>     #10 0x5649c53eeedc in LV::Bin::run() [..]/libvisual/tools/lv-tool/lv-tool.cpp:108
>     #11 0x5649c53eeedc in main [..]/libvisual/tools/lv-tool/lv-tool.cpp:853
>     #12 0x7f981317e209  (/lib64/libc.so.6+0x2a209)
>
> SUMMARY: AddressSanitizer: new-delete-type-mismatch /var/tmp/portage/sys-devel/gcc-11.3.1_p20221223/work/gcc-11-20221223/libsanitizer/asan/asan_new_delete.cpp:172 in operator delete(void*, unsigned long)
> ==21660==HINT: if you don't care about these errors you may set ASAN_OPTIONS=new_delete_type_mismatch=0
> ==21660==ABORTING
hartwork added a commit that referenced this issue Jan 25, 2023
.. by adding the missing virtual destructor to class Hashable.

ASan output was:
> =================================================================
> ==21660==ERROR: AddressSanitizer: new-delete-type-mismatch on 0x603000079d20 in thread T0:
>   object passed to delete has wrong type:
>   size of the allocated type:   32 bytes;
>   size of the deallocated type: 8 bytes.
>     #0 0x7f98137dc2a7 in operator delete(void*, unsigned long) /var/tmp/portage/sys-devel/gcc-11.3.1_p20221223/work/gcc-11-20221223/libsanitizer/asan/asan_new_delete.cpp:172
>     #1 0x7f9802700116 in Hashtable::RemoveAll() [..]/libvisual-plugins/plugins/actor/G-Force/Common/GeneralTools/Hashtable.cpp:202
>     #2 0x7f980270023f in Hashtable::~Hashtable() [..]/libvisual-plugins/plugins/actor/G-Force/Common/GeneralTools/Hashtable.cpp:32
>     #3 0x7f98026dc9d5 in ExpressionDict::~ExpressionDict() ../../../../plugins/actor/G-Force/Common/math/Headers/ExpressionDict.h:20
>     #4 0x7f98026dc9d5 in WaveShape::~WaveShape() ../../../../plugins/actor/G-Force/GForceCommon/Headers/WaveShape.h:11
>     #5 0x7f98026dc9d5 in GForce::~GForce() [..]/libvisual-plugins/plugins/actor/G-Force/GForceCommon/G-Force.cpp:249
>     #6 0x7f980270e7a5 in lv_gforce_cleanup [..]/libvisual-plugins/plugins/actor/G-Force/unix/libvisual/actor_gforce.cpp:140
>     #7 0x7f981367e236 in visual_plugin_unload [..]/libvisual/libvisual/lv_plugin.c:655
>     #8 0x7f9813674563 in actor_dtor [..]/libvisual/libvisual/lv_actor.c:52
>     #9 0x7f98136aa9e8 in visual_object_destroy [..]/libvisual/libvisual/lv_object.c:104
>     #10 0x7f981367c090 in visual_bin_switch_finalize [..]/libvisual/libvisual/lv_bin.c:695
>     #11 0x7f981367c9dd in visual_bin_run [..]/libvisual/libvisual/lv_bin.c:853
>     #12 0x5649c53eeedc in LV::Bin::run() [..]/libvisual/tools/lv-tool/lv-tool.cpp:108
>     #13 0x5649c53eeedc in main [..]/libvisual/tools/lv-tool/lv-tool.cpp:853
>     #14 0x7f981317e209  (/lib64/libc.so.6+0x2a209)
>     #15 0x7f981317e2bb in __libc_start_main (/lib64/libc.so.6+0x2a2bb)
>     #16 0x5649c53f2110 in _start ([..]/INSTALL_PREFIX/bin/lv-tool+0xa110)
>
> 0x603000079d20 is located 0 bytes inside of 32-byte region [0x603000079d20,0x603000079d40)
> allocated by thread T0 here:
>     #0 0x7f98137db247 in operator new(unsigned long) /var/tmp/portage/sys-devel/gcc-11.3.1_p20221223/work/gcc-11-20221223/libsanitizer/asan/asan_new_delete.cpp:99
>     #1 0x7f98026edd5e in ExpressionDict::AddVar(char*, float*) [..]/libvisual-plugins/plugins/actor/G-Force/Common/math/ExpressionDict.cpp:15
>     #2 0x7f98026e9331 in ExpressionDict::AddVar(UtilStr&, float*) [..]/libvisual-plugins/plugins/actor/G-Force/Common/math/Headers/ExpressionDict.h:27
>     #3 0x7f98026e9331 in ExprArray::Compile(ArgList const&, long, ExpressionDict&) [..]/libvisual-plugins/plugins/actor/G-Force/Common/math/ExprArray.cpp:67
>     #4 0x7f98026e0900 in WaveShape::Load(ArgList&, long) [..]/libvisual-plugins/plugins/actor/G-Force/GForceCommon/WaveShape.cpp:76
>     #5 0x7f98026d898d in GForce::loadWaveShape(long, bool) [..]/libvisual-plugins/plugins/actor/G-Force/GForceCommon/G-Force.cpp:1251
>     #6 0x7f98026db109 in GForce::RecordSample(long) [..]/libvisual-plugins/plugins/actor/G-Force/GForceCommon/G-Force.cpp:917
>     #7 0x7f980270ea8e in lv_gforce_render [..]/libvisual-plugins/plugins/actor/G-Force/unix/libvisual/actor_gforce.cpp:264
>     #8 0x7f98136767de in visual_actor_run [..]/libvisual/libvisual/lv_actor.c:777
>     #9 0x7f981367c71a in visual_bin_run [..]/libvisual/libvisual/lv_bin.c:865
>     #10 0x5649c53eeedc in LV::Bin::run() [..]/libvisual/tools/lv-tool/lv-tool.cpp:108
>     #11 0x5649c53eeedc in main [..]/libvisual/tools/lv-tool/lv-tool.cpp:853
>     #12 0x7f981317e209  (/lib64/libc.so.6+0x2a209)
>
> SUMMARY: AddressSanitizer: new-delete-type-mismatch /var/tmp/portage/sys-devel/gcc-11.3.1_p20221223/work/gcc-11-20221223/libsanitizer/asan/asan_new_delete.cpp:172 in operator delete(void*, unsigned long)
> ==21660==HINT: if you don't care about these errors you may set ASAN_OPTIONS=new_delete_type_mismatch=0
> ==21660==ABORTING
hartwork added a commit that referenced this issue Feb 14, 2023
Could be triggered by resizing the window to be of tiny width.

m_reflArray is an array of int elements and all loops oprate on
"m_real_height - m_height" elements.  So if the loop code is correct,
then we need "(m_real_height - m_height) * sizeof(int)" many bytes
for m_reflArray.

Symptom through the eyes of AddressSanitizer:
> =================================================================
> ==20990==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61400000cbec at pc 0x7fe65de62216 bp 0x7ffd745ec810 sp 0x7ffd745ec808
> WRITE of size 4 at 0x61400000cbec thread T0
>     #0 0x7fe65de62215 in Corona::genReflectedWaves(double) [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:311
>     #1 0x7fe65de62262 in Corona::drawReflected() [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:317
>     #2 0x7fe65de6369f in Corona::update(TimedLevel*) [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:504
>     #3 0x7fe65de5fe22 in lv_corona_render [..]/libvisual-plugins/plugins/actor/corona/actor_corona.cpp:278
>     #4 0x7fe66286edb4 in visual_actor_run [..]/libvisual/libvisual/lv_actor.c:783
>     #5 0x7fe662874aac in visual_bin_run [..]/libvisual/libvisual/lv_bin.c:867
>     #6 0x55a1ec4d51ee in LV::Bin::run() [..]/libvisual/tools/lv-tool/lv-tool.cpp:111
>     #7 0x55a1ec4d51ee in main [..]/libvisual/tools/lv-tool/lv-tool.cpp:869
>     #8 0x7fe6624a8d09 in __libc_start_main ../csu/libc-start.c:308
>     #9 0x55a1ec4d2889 in _start ([..]/INSTALL_PREFIX/bin/lv-tool+0x5889)
>
> 0x61400000cbec is located 0 bytes to the right of 428-byte region [0x61400000ca40,0x61400000cbec)
> allocated by thread T0 here:
>     #0 0x7fe662a2ae8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     #1 0x7fe65de612d2 in Corona::setUpSurface(int, int) [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:109
>     #2 0x7fe65de602ed in lv_corona_dimension [..]/libvisual-plugins/plugins/actor/corona/actor_corona.cpp:198
>     #3 0x7fe65de604a9 in lv_corona_events [..]/libvisual-plugins/plugins/actor/corona/actor_corona.cpp:210
>     #4 0x7fe662875b94 in visual_plugin_events_pump [..]/libvisual/libvisual/lv_plugin.c:241
>     #5 0x7fe66286e6d2 in negotiate_video [..]/libvisual/libvisual/lv_actor.c:613
>     #6 0x7fe66286e6d2 in visual_actor_video_negotiate [..]/libvisual/libvisual/lv_actor.c:538
>     #7 0x7fe6628718c4 in visual_bin_sync [..]/libvisual/libvisual/lv_bin.c:346
>     #8 0x55a1ec4d640f in LV::Bin::sync(bool) [..]/libvisual/tools/lv-tool/lv-tool.cpp:103
>     #9 0x55a1ec4d640f in main [..]/libvisual/tools/lv-tool/lv-tool.cpp:926
>     #10 0x7fe6624a8d09 in __libc_start_main ../csu/libc-start.c:308
>
> SUMMARY: AddressSanitizer: heap-buffer-overflow [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:311 in Corona::genReflectedWaves(double)
> Shadow bytes around the buggy address:
>   0x0c287fff9920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c287fff9930: 00 00 00 00 00 00 00 00 00 00 00 00 06 fa fa fa
>   0x0c287fff9940: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
>   0x0c287fff9950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c287fff9960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0c287fff9970: 00 00 00 00 00 00 00 00 00 00 00 00 00[04]fa fa
>   0x0c287fff9980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff9990: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff99a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff99b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff99c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:           00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:       fa
>   Freed heap region:       fd
>   Stack left redzone:      f1
>   Stack mid redzone:       f2
>   Stack right redzone:     f3
>   Stack after return:      f5
>   Stack use after scope:   f8
>   Global redzone:          f9
>   Global init order:       f6
>   Poisoned by user:        f7
>   Container overflow:      fc
>   Array cookie:            ac
>   Intra object redzone:    bb
>   ASan internal:           fe
>   Left alloca redzone:     ca
>   Right alloca redzone:    cb
>   Shadow gap:              cc
> ==20990==ABORTING
hartwork added a commit that referenced this issue Feb 14, 2023
Could be triggered by resizing the window to be of tiny width.

m_reflArray is an array of int elements and all loops operate on
"m_real_height - m_height" elements.  So if the loop code is correct,
then we need "(m_real_height - m_height) * sizeof(int)" many bytes
for m_reflArray.

Symptom through the eyes of AddressSanitizer:
> =================================================================
> ==20990==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61400000cbec at pc 0x7fe65de62216 bp 0x7ffd745ec810 sp 0x7ffd745ec808
> WRITE of size 4 at 0x61400000cbec thread T0
>     #0 0x7fe65de62215 in Corona::genReflectedWaves(double) [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:311
>     #1 0x7fe65de62262 in Corona::drawReflected() [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:317
>     #2 0x7fe65de6369f in Corona::update(TimedLevel*) [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:504
>     #3 0x7fe65de5fe22 in lv_corona_render [..]/libvisual-plugins/plugins/actor/corona/actor_corona.cpp:278
>     #4 0x7fe66286edb4 in visual_actor_run [..]/libvisual/libvisual/lv_actor.c:783
>     #5 0x7fe662874aac in visual_bin_run [..]/libvisual/libvisual/lv_bin.c:867
>     #6 0x55a1ec4d51ee in LV::Bin::run() [..]/libvisual/tools/lv-tool/lv-tool.cpp:111
>     #7 0x55a1ec4d51ee in main [..]/libvisual/tools/lv-tool/lv-tool.cpp:869
>     #8 0x7fe6624a8d09 in __libc_start_main ../csu/libc-start.c:308
>     #9 0x55a1ec4d2889 in _start ([..]/INSTALL_PREFIX/bin/lv-tool+0x5889)
>
> 0x61400000cbec is located 0 bytes to the right of 428-byte region [0x61400000ca40,0x61400000cbec)
> allocated by thread T0 here:
>     #0 0x7fe662a2ae8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     #1 0x7fe65de612d2 in Corona::setUpSurface(int, int) [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:109
>     #2 0x7fe65de602ed in lv_corona_dimension [..]/libvisual-plugins/plugins/actor/corona/actor_corona.cpp:198
>     #3 0x7fe65de604a9 in lv_corona_events [..]/libvisual-plugins/plugins/actor/corona/actor_corona.cpp:210
>     #4 0x7fe662875b94 in visual_plugin_events_pump [..]/libvisual/libvisual/lv_plugin.c:241
>     #5 0x7fe66286e6d2 in negotiate_video [..]/libvisual/libvisual/lv_actor.c:613
>     #6 0x7fe66286e6d2 in visual_actor_video_negotiate [..]/libvisual/libvisual/lv_actor.c:538
>     #7 0x7fe6628718c4 in visual_bin_sync [..]/libvisual/libvisual/lv_bin.c:346
>     #8 0x55a1ec4d640f in LV::Bin::sync(bool) [..]/libvisual/tools/lv-tool/lv-tool.cpp:103
>     #9 0x55a1ec4d640f in main [..]/libvisual/tools/lv-tool/lv-tool.cpp:926
>     #10 0x7fe6624a8d09 in __libc_start_main ../csu/libc-start.c:308
>
> SUMMARY: AddressSanitizer: heap-buffer-overflow [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:311 in Corona::genReflectedWaves(double)
> Shadow bytes around the buggy address:
>   0x0c287fff9920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c287fff9930: 00 00 00 00 00 00 00 00 00 00 00 00 06 fa fa fa
>   0x0c287fff9940: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
>   0x0c287fff9950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c287fff9960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0c287fff9970: 00 00 00 00 00 00 00 00 00 00 00 00 00[04]fa fa
>   0x0c287fff9980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff9990: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff99a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff99b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff99c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:           00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:       fa
>   Freed heap region:       fd
>   Stack left redzone:      f1
>   Stack mid redzone:       f2
>   Stack right redzone:     f3
>   Stack after return:      f5
>   Stack use after scope:   f8
>   Global redzone:          f9
>   Global init order:       f6
>   Poisoned by user:        f7
>   Container overflow:      fc
>   Array cookie:            ac
>   Intra object redzone:    bb
>   ASan internal:           fe
>   Left alloca redzone:     ca
>   Right alloca redzone:    cb
>   Shadow gap:              cc
> ==20990==ABORTING
hartwork added a commit that referenced this issue Feb 16, 2023
Could be triggered by resizing the window to be of tiny width.

m_reflArray is an array of int elements and all loops operate on
"m_real_height - m_height" elements.  So if the loop code is correct,
then we need "(m_real_height - m_height) * sizeof(int)" many bytes
for m_reflArray.

Symptom through the eyes of AddressSanitizer:
> =================================================================
> ==20990==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61400000cbec at pc 0x7fe65de62216 bp 0x7ffd745ec810 sp 0x7ffd745ec808
> WRITE of size 4 at 0x61400000cbec thread T0
>     #0 0x7fe65de62215 in Corona::genReflectedWaves(double) [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:311
>     #1 0x7fe65de62262 in Corona::drawReflected() [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:317
>     #2 0x7fe65de6369f in Corona::update(TimedLevel*) [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:504
>     #3 0x7fe65de5fe22 in lv_corona_render [..]/libvisual-plugins/plugins/actor/corona/actor_corona.cpp:278
>     #4 0x7fe66286edb4 in visual_actor_run [..]/libvisual/libvisual/lv_actor.c:783
>     #5 0x7fe662874aac in visual_bin_run [..]/libvisual/libvisual/lv_bin.c:867
>     #6 0x55a1ec4d51ee in LV::Bin::run() [..]/libvisual/tools/lv-tool/lv-tool.cpp:111
>     #7 0x55a1ec4d51ee in main [..]/libvisual/tools/lv-tool/lv-tool.cpp:869
>     #8 0x7fe6624a8d09 in __libc_start_main ../csu/libc-start.c:308
>     #9 0x55a1ec4d2889 in _start ([..]/INSTALL_PREFIX/bin/lv-tool+0x5889)
>
> 0x61400000cbec is located 0 bytes to the right of 428-byte region [0x61400000ca40,0x61400000cbec)
> allocated by thread T0 here:
>     #0 0x7fe662a2ae8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     #1 0x7fe65de612d2 in Corona::setUpSurface(int, int) [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:109
>     #2 0x7fe65de602ed in lv_corona_dimension [..]/libvisual-plugins/plugins/actor/corona/actor_corona.cpp:198
>     #3 0x7fe65de604a9 in lv_corona_events [..]/libvisual-plugins/plugins/actor/corona/actor_corona.cpp:210
>     #4 0x7fe662875b94 in visual_plugin_events_pump [..]/libvisual/libvisual/lv_plugin.c:241
>     #5 0x7fe66286e6d2 in negotiate_video [..]/libvisual/libvisual/lv_actor.c:613
>     #6 0x7fe66286e6d2 in visual_actor_video_negotiate [..]/libvisual/libvisual/lv_actor.c:538
>     #7 0x7fe6628718c4 in visual_bin_sync [..]/libvisual/libvisual/lv_bin.c:346
>     #8 0x55a1ec4d640f in LV::Bin::sync(bool) [..]/libvisual/tools/lv-tool/lv-tool.cpp:103
>     #9 0x55a1ec4d640f in main [..]/libvisual/tools/lv-tool/lv-tool.cpp:926
>     #10 0x7fe6624a8d09 in __libc_start_main ../csu/libc-start.c:308
>
> SUMMARY: AddressSanitizer: heap-buffer-overflow [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:311 in Corona::genReflectedWaves(double)
> Shadow bytes around the buggy address:
>   0x0c287fff9920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c287fff9930: 00 00 00 00 00 00 00 00 00 00 00 00 06 fa fa fa
>   0x0c287fff9940: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
>   0x0c287fff9950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c287fff9960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0c287fff9970: 00 00 00 00 00 00 00 00 00 00 00 00 00[04]fa fa
>   0x0c287fff9980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff9990: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff99a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff99b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff99c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:           00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:       fa
>   Freed heap region:       fd
>   Stack left redzone:      f1
>   Stack mid redzone:       f2
>   Stack right redzone:     f3
>   Stack after return:      f5
>   Stack use after scope:   f8
>   Global redzone:          f9
>   Global init order:       f6
>   Poisoned by user:        f7
>   Container overflow:      fc
>   Array cookie:            ac
>   Intra object redzone:    bb
>   ASan internal:           fe
>   Left alloca redzone:     ca
>   Right alloca redzone:    cb
>   Shadow gap:              cc
> ==20990==ABORTING
hartwork added a commit that referenced this issue Feb 19, 2023
Could be triggered by resizing the window to be of tiny width.

m_reflArray is an array of int elements and all loops operate on
"m_real_height - m_height" elements.  So if the loop code is correct,
then we need "(m_real_height - m_height) * sizeof(int)" many bytes
for m_reflArray.

Symptom through the eyes of AddressSanitizer:
> =================================================================
> ==20990==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61400000cbec at pc 0x7fe65de62216 bp 0x7ffd745ec810 sp 0x7ffd745ec808
> WRITE of size 4 at 0x61400000cbec thread T0
>     #0 0x7fe65de62215 in Corona::genReflectedWaves(double) [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:311
>     #1 0x7fe65de62262 in Corona::drawReflected() [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:317
>     #2 0x7fe65de6369f in Corona::update(TimedLevel*) [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:504
>     #3 0x7fe65de5fe22 in lv_corona_render [..]/libvisual-plugins/plugins/actor/corona/actor_corona.cpp:278
>     #4 0x7fe66286edb4 in visual_actor_run [..]/libvisual/libvisual/lv_actor.c:783
>     #5 0x7fe662874aac in visual_bin_run [..]/libvisual/libvisual/lv_bin.c:867
>     #6 0x55a1ec4d51ee in LV::Bin::run() [..]/libvisual/tools/lv-tool/lv-tool.cpp:111
>     #7 0x55a1ec4d51ee in main [..]/libvisual/tools/lv-tool/lv-tool.cpp:869
>     #8 0x7fe6624a8d09 in __libc_start_main ../csu/libc-start.c:308
>     #9 0x55a1ec4d2889 in _start ([..]/INSTALL_PREFIX/bin/lv-tool+0x5889)
>
> 0x61400000cbec is located 0 bytes to the right of 428-byte region [0x61400000ca40,0x61400000cbec)
> allocated by thread T0 here:
>     #0 0x7fe662a2ae8f in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
>     #1 0x7fe65de612d2 in Corona::setUpSurface(int, int) [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:109
>     #2 0x7fe65de602ed in lv_corona_dimension [..]/libvisual-plugins/plugins/actor/corona/actor_corona.cpp:198
>     #3 0x7fe65de604a9 in lv_corona_events [..]/libvisual-plugins/plugins/actor/corona/actor_corona.cpp:210
>     #4 0x7fe662875b94 in visual_plugin_events_pump [..]/libvisual/libvisual/lv_plugin.c:241
>     #5 0x7fe66286e6d2 in negotiate_video [..]/libvisual/libvisual/lv_actor.c:613
>     #6 0x7fe66286e6d2 in visual_actor_video_negotiate [..]/libvisual/libvisual/lv_actor.c:538
>     #7 0x7fe6628718c4 in visual_bin_sync [..]/libvisual/libvisual/lv_bin.c:346
>     #8 0x55a1ec4d640f in LV::Bin::sync(bool) [..]/libvisual/tools/lv-tool/lv-tool.cpp:103
>     #9 0x55a1ec4d640f in main [..]/libvisual/tools/lv-tool/lv-tool.cpp:926
>     #10 0x7fe6624a8d09 in __libc_start_main ../csu/libc-start.c:308
>
> SUMMARY: AddressSanitizer: heap-buffer-overflow [..]/libvisual-plugins/plugins/actor/corona/corona.cpp:311 in Corona::genReflectedWaves(double)
> Shadow bytes around the buggy address:
>   0x0c287fff9920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c287fff9930: 00 00 00 00 00 00 00 00 00 00 00 00 06 fa fa fa
>   0x0c287fff9940: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
>   0x0c287fff9950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0c287fff9960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0c287fff9970: 00 00 00 00 00 00 00 00 00 00 00 00 00[04]fa fa
>   0x0c287fff9980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff9990: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff99a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff99b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x0c287fff99c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:           00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:       fa
>   Freed heap region:       fd
>   Stack left redzone:      f1
>   Stack mid redzone:       f2
>   Stack right redzone:     f3
>   Stack after return:      f5
>   Stack use after scope:   f8
>   Global redzone:          f9
>   Global init order:       f6
>   Poisoned by user:        f7
>   Container overflow:      fc
>   Array cookie:            ac
>   Intra object redzone:    bb
>   ASan internal:           fe
>   Left alloca redzone:     ca
>   Right alloca redzone:    cb
>   Shadow gap:              cc
> ==20990==ABORTING

(cherry picked from commit 04ab908)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants