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

Ignore ASAN failure in UnitTestImpl #3022

Merged
merged 1 commit into from
Aug 12, 2024

Conversation

kevinbackhouse
Copy link
Collaborator

The on_PR_mac_special_builds.yml workflow keeps failing due to an ASAN failure during unit testing. It looks like the problem is in the unit testing library, which isn't our code, so this PR fixes it by silencing the error.

This is an example of the error message:

7/7 Test #7: unitTests ........................Subprocess aborted***Exception:   0.82 sec
=================================================================
==8381==ERROR: AddressSanitizer: container-overflow on address 0x00010500123f at pc 0x0001005bd9d4 bp 0x00016f88ace0 sp 0x00016f88acd8
READ of size 1 at 0x00010500123f thread T0
    #0 0x1005bd9d0 in std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>::__base_destruct_at_end[abi:ue170006](std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*)+0x1[20](https://github.com/Exiv2/exiv2/actions/runs/10228533538/job/28301173586#step:5:21) (unit_tests:arm64+0x10004d9d0)
    #1 0x1005bd680 in std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>::__destroy_vector::operator()[abi:ue170006]()+0x60 (unit_tests:arm64+0x10004d680)
    #2 0x1009e7ab4 in testing::internal::UnitTestImpl::GetTestSuite(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, char const*, void (*)(), void (*)())+0x2d4 (unit_tests:arm64+0x100477ab4)
    #3 0x1009da834 in testing::internal::UnitTestImpl::AddTestInfo(void (*)(), void (*)(), testing::TestInfo*)+0xf8 (unit_tests:arm64+0x10046a834)
    #4 0x1009da6c8 in testing::internal::MakeAndRegisterTestInfo(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, char const*, char const*, char const*, testing::internal::CodeLocation, void const*, void (*)(), void (*)(), testing::internal::TestFactoryBase*)+0xfc (unit_tests:arm64+0x10046a6c8)
    #5 0x1007cb074 in _GLOBAL__sub_I_test_basicio.cpp+0x2c0 (unit_tests:arm64+0x10025b074)
    #6 0x194541058  (<unknown module>)
    #7 0x19457f304  (<unknown module>)
    #8 0x194572998 in invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const+0x1ec (dyld:arm64e+0xfffffffffff9a998)
    #9 0x1945222f8  (<unknown module>)
    #10 0x19457192c in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const+0xbc (dyld:arm64e+0xfffffffffff9992c)
    #11 0x19457ee18  (<unknown module>)
    #12 0x19453d06c  (<unknown module>)
    #13 0x194543610  (<unknown module>)
    #14 0x19453d458  (<unknown module>)
    #15 0x1945410e8  (<unknown module>)
    #16 0x19453d624  (<unknown module>)
    #17 0x1945604d4  (<unknown module>)
    #18 0x194526f78  (<unknown module>)
    #19 0x194525ed8  (<unknown module>)

0x00010500123f is located 47 bytes inside of 48-byte region [0x000105001[21](https://github.com/Exiv2/exiv2/actions/runs/10228533538/job/28301173586#step:5:22)0,0x000105001240)
allocated by thread T0 here:
    #0 0x101a6974c in wrap__Znwm+0x74 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x6174c)
    #1 0x1009eaf78 in std::__1::__allocation_result<std::__1::allocator_traits<std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>::pointer> std::__1::__allocate_at_least[abi:ue170006]<std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>(std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>&, unsigned long)+0x2c (unit_tests:arm64+0x10047af78)
    #2 0x1009eae2c in std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>::reserve(unsigned long)+0x58 (unit_tests:arm64+0x10047ae2c)
    #3 0x1009d3214 in testing::internal::(anonymous namespace)::UnitTestFilter::UnitTestFilter(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&)+0x8c (unit_tests:arm64+0x100463214)
    #4 0x1009e7908 in testing::internal::UnitTestImpl::GetTestSuite(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, char const*, void (*)(), void (*)())+0x128 (unit_tests:arm64+0x100477908)
    #5 0x1009da834 in testing::internal::UnitTestImpl::AddTestInfo(void (*)(), void (*)(), testing::TestInfo*)+0xf8 (unit_tests:arm64+0x10046a834)
    #6 0x1009da6c8 in testing::internal::MakeAndRegisterTestInfo(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, char const*, char const*, char const*, testing::internal::CodeLocation, void const*, void (*)(), void (*)(), testing::internal::TestFactoryBase*)+0xfc (unit_tests:arm64+0x10046a6c8)
    #7 0x1007cb074 in _GLOBAL__sub_I_test_basicio.cpp+0x2c0 (unit_tests:arm64+0x10025b074)
    #8 0x194541058  (<unknown module>)
    #9 0x19457f304  (<unknown module>)
    #10 0x194572998 in invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const+0x1ec (dyld:arm64e+0xfffffffffff9a998)
    #11 0x1945[22](https://github.com/Exiv2/exiv2/actions/runs/10228533538/job/28301173586#step:5:23)2f8  (<unknown module>)
    #12 0x19457192c in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const+0xbc (dyld:arm64e+0xfffffffffff9992c)
    #13 0x19457ee18  (<unknown module>)
    #14 0x19453d06c  (<unknown module>)
    #15 0x194543610  (<unknown module>)
    #16 0x19453d458  (<unknown module>)
    #17 0x1945410e8  (<unknown module>)
    #18 0x19453d624  (<unknown module>)
    #19 0x1945604d4  (<unknown module>)
    #20 0x194526f78  (<unknown module>)
    #21 0x194525ed8  (<unknown module>)

HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_container_overflow=0.
If you suspect a false positive see also: https://github.com/google/sanitizers/wiki/AddressSanitizerContainerOverflow.
SUMMARY: AddressSanitizer: container-overflow (unit_tests:arm64+0x10004d9d0) in std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>::__base_destruct_at_end[abi:ue170006](std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>*)+0x120
Shadow bytes around the buggy address:
  0x000105000f80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x000105001000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x000105001080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x000105001100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x000105001180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x000105001200: fa fa fc fc fc fc fc[fc]fa fa fd fd fd fd fd fd
  0x000105001[28](https://github.com/Exiv2/exiv2/actions/runs/10228533538/job/28301173586#step:5:29)0: fa fa 00 00 00 00 00 00 fa fa 00 00 00 00 00 00
  0x000105001300: fa fa 00 00 00 00 00 fa fa fa fd fd fd fd fd fa
  0x000105001380: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 00 00
  0x000105001400: fa fa 00 00 00 00 00 00 fa fa 00 00 00 00 00 00
  0x000105001480: fa fa 00 00 00 00 00 00 fa fa 00 00 00 00 00 00
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
==8[38](https://github.com/Exiv2/exiv2/actions/runs/10228533538/job/28301173586#step:5:39)1==ABORTING

Errors while running CTest

86% tests passed, 1 tests failed out of 7

Total Test time (real) = 143.89 sec

The following tests FAILED:
	  7 - unitTests (Subprocess aborted)
Error: Process completed with exit code 8.

@kevinbackhouse
Copy link
Collaborator Author

@Mergifyio backport 0.28.x

Copy link
Contributor

mergify bot commented Aug 4, 2024

backport 0.28.x

✅ Backports have been created

@kevinbackhouse kevinbackhouse added CI Issues related with CI jobs testing Anything related to the tests and their infrastructure labels Aug 4, 2024
@kmilos
Copy link
Collaborator

kmilos commented Aug 5, 2024

It looks like the problem is in the unit testing library

Is there a reference for this, or some clue it'll get addressed?

@kevinbackhouse
Copy link
Collaborator Author

It looks like the problem is in the unit testing library

Is there a reference for this, or some clue it'll get addressed?

No, I haven't found anything. This is just my assumption based on the stack trace, which shows that the error is in testing::internal::UnitTestImpl, which isn't our code. I don't have a Mac, so I can't easily investigate this further. That's why I chose the easy option of silencing the error.

@neheb neheb merged commit 0be19b7 into Exiv2:main Aug 12, 2024
58 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI Issues related with CI jobs testing Anything related to the tests and their infrastructure
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants