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

Question: Folder structure #1

Closed
Zingam opened this issue Jul 5, 2018 · 1 comment
Closed

Question: Folder structure #1

Zingam opened this issue Jul 5, 2018 · 1 comment

Comments

@Zingam
Copy link

Zingam commented Jul 5, 2018

Thank you for the pre-compiled redistributes!

Do the .zip files found here:
https://shiftmediaproject.github.io/
have the default folder structure that is created by the install/build command of the source libraries?
I wonder if the CMake's modules for the find_package command will work by default or they'll need to be changed to support your distributions?

@Sibras
Copy link
Member

Sibras commented Jul 5, 2018

The folder structure is based on the default linux style of bin/lib etc. However within each of these folders there is a separate arch folder (x86/x64) which there isnt a standard way of doing (often your only allowed to have 1 of those). So the folder structure used is designed to remain consistent over all the binaries provided on the web site for all the different projects. Many of these projects have different ways of arranging installed folder layouts on Windows that dont always align with the standard used here. This means that there isnt really a standard way that find_packages looks for things (it does different things for different projects). Which makes it difficult to support it consistently for all projects.

That said I havnt tested it with libvpx so i dont know whether it picks it up or not. Worst comes to the worst you can simply just move the files provided here into a different structure that it does pick up.

@Sibras Sibras closed this as completed Jul 5, 2018
Sibras pushed a commit that referenced this issue Mar 11, 2023
Fix errors reported by UBSan diagnostics:
1. /vp9/encoder/vp9_pickmode.c:308:29: unsigned integer overflow:
   99 - 100 cannot be represented in type 'unsigned int'
2. /vp9/encoder/vp9_pickmode.c:330:27: unsigned integer overflow:
   21976 - 21978 cannot be represented in type 'unsigned int'
3. /vp9/encoder/vp9_pickmode.c:468:13: unsigned integer overflow:
   18852144 - 18852149 cannot be represented in type 'unsigned int'

(Notice that line numbers might vary a bit because fixes have
been applied incrementally i.e. fix for error #1 affects line
number reported in #2)

Fix by calculating difference instead of wrapping around to
a value near maximum.

Test: Cuttlefish webrtc with VP9 codec
Change-Id: I4f85712028647e915a4e2da31e4b0a266e9e2705
Sibras pushed a commit that referenced this issue Mar 11, 2023
this was added in:
  7beafef vp9: Allow for disabling loopfilter per spatial layer
but the test doesn't zero initialize its svc_params_ member.

fixes the use of an uninitialized value, reported by valgrind and
integer sanitizer:
[ RUN      ] VP9/RcInterfaceSvcTest.Svc/0
==1064682== Conditional jump or move depends on uninitialised value(s)
==1064682==    at 0x1C5624: loopfilter_frame (vp9_encoder.c:3285)
==1064682==    by 0x1C9B54: encode_frame_to_data_rate (vp9_encoder.c:5595)
==1064682==    by 0x1CA2EE: SvcEncode (vp9_encoder.c:5789)
==1064682==    by 0x1CEA01: vp9_get_compressed_data (vp9_encoder.c:7891)
==1064682==    by 0x185F0E: encoder_encode (vp9_cx_iface.c:1437)
==1064682==    by 0x1503BB: vpx_codec_encode (vpx_encoder.c:208)

vp9/encoder/vp9_svc_layercontext.c:362:26: runtime error: implicit
conversion from type 'int' of value -1 (32-bit, signed) to type
'LOOPFILTER_CONTROL' changed the value to 4294967295 (32-bit, unsigned)
    #0 0x558925f45377 in vp9_restore_layer_context vp9/encoder/vp9_svc_layercontext.c:362:26
    #1 0x558925ef89fd in vp9_get_compressed_data vp9/encoder/vp9_encoder.c:7781:5
    #2 0x558925e3ef3e in encoder_encode vp9/vp9_cx_iface.c:1437:20

Bug: b/229626362
Change-Id: I33d244be7752c68b71efa9c62ca45d6b202ec761
Sibras pushed a commit that referenced this issue Apr 6, 2024
This reverts commit 360e906.

This causes ASan errors:
[ RUN      ] VP9/TestVectorTest.MD5Match/1
=================================================================
==837858==ERROR: AddressSanitizer: stack-buffer-overflow on address
0xffff82ecad40 at pc 0x000000c494d4 bp 0xffffe1695800 sp 0xffffe16957f8
READ of size 16 at 0xffff82ecad40 thread T0
    #0 0xc494d0 in vpx_d117_predictor_32x32_neon (test_libvpx+0xc494d0)
    #1 0x1040b34 in vp9_predict_intra_block (test_libvpx+0x1040b34)
    #2 0xf8feec in decode_block (test_libvpx+0xf8feec)
    #3 0xf8f588 in decode_partition (test_libvpx+0xf8f588)
    #4 0xf7be5c in vp9_decode_frame (test_libvpx+0xf7be5c)
    ...
Address 0xffff82ecad40 is located in stack of thread T0 at offset 64 in
frame
    #0 0x103fd3c in vp9_predict_intra_block (test_libvpx+0x103fd3c)

  This frame has 2 object(s):
    [32, 64) 'left_col.i' <== Memory access at offset 64 overflows this
                              variable
    [96, 176) 'above_data.i'

Change-Id: I058213364617dfe1036126c33a3307f8288d9ae0
Sibras pushed a commit that referenced this issue Apr 6, 2024
This function causes a heap overflow in the tests:
[ RUN      ] NEON/VpxSseTest.RefSse/0
=================================================================
==876922==ERROR: AddressSanitizer: heap-buffer-overflow on address
0xffff8949d903 at pc 0x000000dd95d4 bp 0xfffffdd7f260 sp 0xfffffdd7f258
READ of size 8 at 0xffff8949d903 thread T0
    #0 0xdd95d0 in vpx_get4x4sse_cs_neon
       vpx_dsp/arm/variance_neon.c:556:10
    #1 0x9d4894 in (anonymous namespace)::MainTestClass<unsigned int
       (*)(unsigned char const*, int, unsigned char const*,
           int)>::RefTestSse() test/variance_test.cc:531:5
    #2 0x9d4894 in (anonymous
       namespace)::VpxSseTest_RefSse_Test::TestBody()
           test/variance_test.cc:772:30
    ...

0xffff8949d903 is located 3 bytes to the right of 16-byte region
[0xffff8949d8f0,0xffff8949d900)
allocated by thread T0 here:
    #0 0x5fd050 in operator new[](unsigned long) (test_libvpx+0x5fd050)
    #1 0x9d3e04 in (anonymous namespace)::MainTestClass<unsigned int
       (*)(unsigned char const*, int, unsigned char const*,
           int)>::SetUp() test/variance_test.cc:299:12

Bug: webm:1794
Change-Id: I4bc681eb9a436743ef8bfe2a2abae59ce754309c
Sibras pushed a commit that referenced this issue Apr 6, 2024
This causes various buffer overflows in the tests:

[ RUN      ] NEON/SixtapPredictTest.TestWithPresetData/0
=================================================================
==22346==ERROR: AddressSanitizer: global-buffer-overflow on address
0x0000012b4a5b at pc 0x000000df0f60 bp 0xffffcf6e64b0 sp 0xffffcf6e64a8
READ of size 8 at 0x0000012b4a5b thread T0
    #0 0xdf0f5c in vp8_sixtap_predict16x16_neon
       vp8/common/arm/neon/sixtappredict_neon.c:1507:13
    #1 0x8819e4 in (anonymous
        namespace)::SixtapPredictTest_TestWithPresetData_Test::TestBody()
       test/predict_test.cc:293:3
    ...

0x0000012b4a5b is located 2 bytes to the right of global variable
'kTestData' defined in '../test/predict_test.cc:237:24' (0x12b48a0) of
size 441

[ RUN      ] NEON/SixtapPredictTest.TestWithRandomData/0
=================================================================
==22338==ERROR: AddressSanitizer: heap-buffer-overflow on address
0xffff8b5321fb at pc 0x000000df0f60 bp 0xfffff7e0cf30 sp 0xfffff7e0cf28
READ of size 8 at 0xffff8b5321fb thread T0
    #0 0xdf0f5c in vp8_sixtap_predict16x16_neon
       vp8/common/arm/neon/sixtappredict_neon.c:1507:13
    #1 0x87d4c0 in (anonymous
       namespace)::PredictTestBase::TestWithRandomData(void (*)(unsigned
       char*, int, int, int, unsigned char*, int))
       test/predict_test.cc:170:9
    ...

0xffff8b5321fb is located 2 bytes to the right of 441-byte region
[0xffff8b532040,0xffff8b5321f9)
allocated by thread T0 here:
    #0 0x5fd4f0 in operator new[](unsigned long) (test_libvpx+0x5fd4f0)
    #1 0x87c2e0 in (anonymous namespace)::PredictTestBase::SetUp()
       test/predict_test.cc:47:12
    #2 0x87d074 in non-virtual thunk to (anonymous
       namespace)::PredictTestBase::SetUp() test/predict_test.cc
    ...

Bug: webm:1795
Change-Id: I32213a381eef91547d00f88acf90f1cf2ec2ea75
Sibras pushed a commit that referenced this issue Apr 6, 2024
Fixes a -fsanitize=undefined warning:

vpx_dsp/arm/vpx_convolve_copy_neon.c:29:26: runtime error: load of
misaligned address 0xffffa8242bea for type 'const uint32_t' (aka 'const
unsigned int'), which requires 4 byte alignment
0xffffa8242bea: note: pointer points here
 88 81  7d 7d 7d 7d 7d 81 81 7d  81 80 87 97 a8 ab a0 91 ...
              ^
    #0 0xb0447c in vpx_convolve_copy_neon
       vpx_dsp/arm/vpx_convolve_copy_neon.c:29:26
    #1 0x12285c8 in inter_predictor vp9/common/vp9_reconinter.h:29:3
    #2 0x1228430 in dec_build_inter_predictors
       vp9/decoder/vp9_decodeframe.c
    ...

Change-Id: Iaec4ac2a400b6e6db72d12e5a7acb316262b12a7
Sibras pushed a commit that referenced this issue Apr 6, 2024
vpx_highbd_8_sub_pixel_variance4x4_neon
vpx_highbd_8_sub_pixel_variance4x8_neon
vpx_highbd_10_sub_pixel_variance4x4_neon
vpx_highbd_10_sub_pixel_variance4x8_neon
vpx_highbd_12_sub_pixel_variance4x4_neon
vpx_highbd_12_sub_pixel_variance4x8_neon

all cause heap overflows of the form:

[ RUN      ] NEON/VpxHBDSubpelVarianceTest.Ref/24
=================================================================
==450528==ERROR: AddressSanitizer: heap-buffer-overflow on address
0xffff8311a571 at pc 0x0000010ca52c bp 0xffffc63e96b0 sp 0xffffc63e96a8
READ of size 8 at 0xffff8311a571 thread T0
    #0 0x10ca528 in load_unaligned_u16q vpx_dsp/arm/mem_neon.h:176:3
    #1 0x10ca528 in highbd_var_filter_block2d_bil_w4
       vpx_dsp/arm/highbd_subpel_variance_neon.c:49:21
    #2 0x10ca528 in vpx_highbd_10_sub_pixel_variance4x8_neon
       vpx_dsp/arm/highbd_subpel_variance_neon.c:257:1
    ...

0xffff8311a571 is located 0 bytes to the right of 113-byte region
[0xffff8311a500,0xffff8311a571)
allocated by thread T0 here:
    #0 0x5f18b0 in malloc (test_libvpx+0x5f18b0)
    #1 0xce4f90 in vpx_memalign vpx_mem/vpx_mem.c:62:10
    #2 0xce4f90 in vpx_malloc vpx_mem/vpx_mem.c:70:40
    #3 0xa4ad44 in (anonymous namespace)::SubpelVarianceTest<unsigned
       int (*)(unsigned char const*, int, int, int, unsigned char
       const*, int, unsigned int*)>::SetUp() test/variance_test.cc:586:14

Bug: webm:1796
Change-Id: I39f7f936bae2bcbbe1f803fb10375ec02d1c1277
Sibras pushed a commit that referenced this issue Apr 6, 2024
vpx_highbd_8_sub_pixel_avg_variance4x4_neon
vpx_highbd_8_sub_pixel_avg_variance4x8_neon
vpx_highbd_10_sub_pixel_avg_variance4x4_neon
vpx_highbd_10_sub_pixel_avg_variance4x8_neon
vpx_highbd_12_sub_pixel_avg_variance4x4_neon
vpx_highbd_12_sub_pixel_avg_variance4x8_neon

all cause heap overflows of the form:

i[ RUN      ] NEON/VpxHBDSubpelAvgVarianceTest.Ref/33
=================================================================
==535205==ERROR: AddressSanitizer: heap-buffer-overflow on address
0xffff95bb0b89 at pc 0x00000116dabc bp 0xffffd09f6430 sp 0xffffd09f6428
READ of size 8 at 0xffff95bb0b89 thread T0
    #0 0x116dab8 in load_unaligned_u16q vpx_dsp/arm/mem_neon.h:176:3
    #1 0x116dab8 in highbd_var_filter_block2d_bil_w4
       vpx_dsp/arm/highbd_subpel_variance_neon.c:49:21
    #2 0x116dab8 in vpx_highbd_8_sub_pixel_avg_variance4x4_neon
       vpx_dsp/arm/highbd_subpel_variance_neon.c:543:1
    ...

0xffff95bb0b89 is located 0 bytes to the right of 73-byte region
[0xffff95bb0b40,0xffff95bb0b89)
allocated by thread T0 here:
    #0 0x5f18b0 in malloc (test_libvpx+0x5f18b0)
    #1 0xce4a40 in vpx_memalign vpx_mem/vpx_mem.c:62:10
    #2 0xce4a40 in vpx_malloc vpx_mem/vpx_mem.c:70:40
    #3 0xa52238 in (anonymous namespace)::SubpelVarianceTest<unsigned
       int (*)(unsigned char const*, int, int, int, unsigned char
               const*, int, unsigned int*, unsigned char
               const*)>::SetUp()
       test/variance_test.cc:586:14
    ...

This is the same issue as:
  e33d4c2 disable vpx_highbd_*_sub_pixel_variance4x{4,8}_neon
They have highbd_var_filter_block2d_bil_w4 in common.

Bug: webm:1796
Change-Id: I3ed70d0ba22e127720542612ea9f6665948eedfc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants