-
Notifications
You must be signed in to change notification settings - Fork 159
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
Let's fix the tests enough to run with AddressSanitizer and UB Sanitizer and enable those in CI #1151
Let's fix the tests enough to run with AddressSanitizer and UB Sanitizer and enable those in CI #1151
Commits on Jun 7, 2024
-
unit-test CMake: Add option to build with sanitizers
These build options affect both the tests and the code under test when built from the unit-test CMake file. Example: cmake -DSANITIZE=address,undefined To reset all options: cmake --fresh Meson users will find this familiar: meson -Db_sanitize=… (When in doubt in CMake, implement what Meson provides out of the box.) Motivation: ASan and UBSan currently finds a lot of crashy problems with the unit-tests, and makes them visible in plain sight.
Configuration menu - View commit details
-
Copy full SHA for ff2bd0a - Browse repository at this point
Copy the full SHA ff2bd0aView commit details -
unit-test CMake: Remove compile_options(-O0 -Wno-div-by-zero)
Let's not override optimization options: This is surprising when the cmake user tries to set CMAKE_BUILD_TYPE=(Debug|Release)'. The -Wno-div-by-zero warning disabling seems obsolete: Replacing it with -Werror did not fail, at least with Gcc 13.
Configuration menu - View commit details
-
Copy full SHA for 7821269 - Browse repository at this point
Copy the full SHA 7821269View commit details -
unit-test: Fix missing symbol in a few tests (linker error)
I don't know why I get to resolve these, but in all cases, it is FreeRTOS_Sockets.c that is dragging in a dependency on xTCPWindowLoggingLevel, causing a few tests to fail to link: FreeRTOS_Sockets.c:5118:(.text+0x18fa2): undefined reference to `xTCPWindowLoggingLevel' Since it's one external variable, let's add it to the necessary unittests. Also under the headline of extern variables: The IPv6 address, which was not there for linkage, could be made const.
Configuration menu - View commit details
-
Copy full SHA for 1004eb2 - Browse repository at this point
Copy the full SHA 1004eb2View commit details -
unit-test: Fix segfault due to discrepancy between the real and mocke…
…d recvfrom Symptom: test_vDHCPProcess_eWaitingOffer_CorrectState_ValidBytesInMessage_MatchingEndPoint() segfaults. What AddressSanitizer says about that: test/unit-test/build/Annexed_TCP_Sources/FreeRTOS_DHCP.c:1139:28: runtime error: member access within null pointer of type 'const struct DHCPMessage_IPv4_t' AddressSanitizer:DEADLYSIGNAL ================================================================= ==14403==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000000ec ==14403==The signal is caused by a READ memory access. ==14403==Hint: address points to the zero page. #0 0x456eb7 in prvIsValidDHCPResponse test/unit-test/build/Annexed_TCP_Sources/FreeRTOS_DHCP.c:1139 FreeRTOS#1 0x4584c3 in prvProcessDHCPReplies test/unit-test/build/Annexed_TCP_Sources/FreeRTOS_DHCP.c:1280 FreeRTOS#2 0x45038c in xHandleWaitingOffer test/unit-test/build/Annexed_TCP_Sources/FreeRTOS_DHCP.c:334 FreeRTOS#3 0x45366a in vDHCPProcessEndPoint test/unit-test/build/Annexed_TCP_Sources/FreeRTOS_DHCP.c:735 FreeRTOS#4 0x44fe57 in vDHCPProcess test/unit-test/build/Annexed_TCP_Sources/FreeRTOS_DHCP.c:263 FreeRTOS#5 0x418d2c in test_vDHCPProcess_eWaitingOffer_CorrectState_ValidBytesInMessage_MatchingEndPoint test/unit-test/FreeRTOS_DHCP/FreeRTOS_DHCP_utest.c:147 Diagnosis: pxDHCPMessage in prvProcessDHCPReplies() is the unlucky null pointer. As commented, it is expected to be set as an out-arg of FreeRTOS_recvfrom() due to calling it with FREERTOS_ZERO_COPY, but the condition for it in the mocked FreeRTOS_recvfrom() is that the sum of all flags is FREERTOS_ZERO_COPY + FREERTOS_MSG_PEEK. Finding the right fix: Should we add a null check? Nope. Set the FREERTOS_MSG_PEEK flag? Nope. The mocked function did not check the FREERTOS_ZERO_COPY flag properly. Observe that in the real FreeRTOS_recvfrom(), specifically inside prvRecvFrom_CopyPacket(), the condition for setting the zero-copy pointer into the buffer with the data depends only on one flag - FREERTOS_ZERO_COPY - and ignores the rest. It is obviously important that the mocked condition is exactly the same.
Configuration menu - View commit details
-
Copy full SHA for b3dc4a6 - Browse repository at this point
Copy the full SHA b3dc4a6View commit details -
Configuration menu - View commit details
-
Copy full SHA for 662a57e - Browse repository at this point
Copy the full SHA 662a57eView commit details -
test_prvProcessEthernetPacket_*(): Fix memset(NULL, …) segfaults
The pointer was used before initialized. If it happened to be NULL, the test would segfault.
Configuration menu - View commit details
-
Copy full SHA for 93ae7bd - Browse repository at this point
Copy the full SHA 93ae7bdView commit details -
unit-test: Fix pxEthernetBuffer[-ipIP_TYPE_OFFSET] buffer underflows
The tested functions intentionally expect there to be bytes before the ethernet buffer: * test_FreeRTOS_GetUDPPayloadBuffer_*(): The code under test, FreeRTOS_GetUDPPayloadBuffer_Multi, writes 6 bytes before the ethernet buffer. This looks intentional, as the write is commented as doing that. * FreeRTOS_IP_utest: The code under test, prvProcessIPPacket() intentionally writes a byte at offset -ipIP_TYPE_OFFSET into its ethernet buffer. I am thankful for the generous comment about the ipIP_TYPE_OFFSET.
Configuration menu - View commit details
-
Copy full SHA for 9e0a3a8 - Browse repository at this point
Copy the full SHA 9e0a3a8View commit details -
test_vTCPWindowDestroy_list_length_not_zero(): Fix buffer overflow du…
…e to struct interposing The test was crashing due to what AddressSanitizer calls a buffer overflow, or really, interposing a TCPSegment_t on top of a TCPWindow_t::xRxSegments member and accessing an interposed struct member that fell outside the underlying TCPWindow_t struct. The naive fix - not doing that - works: void test_vTCPWindowDestroy_list_length_not_zero( void ) { TCPWindow_t xWindow = { 0 }; - List_t * pxSegments = &( xWindow.xRxSegments ); + TCPSegment_t xSegment = { 0 }; listLIST_IS_INITIALISED_ExpectAnyArgsAndReturn( pdFALSE ); listLIST_IS_INITIALISED_ExpectAnyArgsAndReturn( pdTRUE ); listCURRENT_LIST_LENGTH_ExpectAnyArgsAndReturn( 1 ); - listGET_OWNER_OF_HEAD_ENTRY_ExpectAnyArgsAndReturn( pxSegments ); + listGET_OWNER_OF_HEAD_ENTRY_ExpectAnyArgsAndReturn( &xSegment ); /* ->vTCPWindowFree */ - uxListRemove_ExpectAnyArgsAndReturn( pdTRUE ); - uxListRemove_ExpectAnyArgsAndReturn( pdTRUE ); listCURRENT_LIST_LENGTH_ExpectAnyArgsAndReturn( 0 ); vTCPWindowDestroy( &xWindow ); } However, this became a different test, as evidenced by the less than 100% line coverage, that two function call expectations had to go, and that it functionally became an exact copy of the next test. To reach the holes in the test coverage opened by the naive fix, the two list items' container pointers also needed and sufficed to be set.
Configuration menu - View commit details
-
Copy full SHA for 8b1ba02 - Browse repository at this point
Copy the full SHA 8b1ba02View commit details -
test_eARPGetCacheEntryByMac_OneMatchingEntry(): Arrest dangling pointer
This test was using the stack of a previously returned function (probably a previous test). Highlights from AddressSanitizer output: ==15832==ERROR: AddressSanitizer: stack-use-after-return READ of size 8 at 0x7fdefb013670 thread T0 #0 0x4325bf in eARPGetCacheEntryByMac source/FreeRTOS_ARP.c:930 FreeRTOS#1 0x421a71 in test_eARPGetCacheEntryByMac_OneMatchingEntry (test/unit-test/build/bin/tests/FreeRTOS_ARP_utest+0x421a71) Address 0x7fdefb013670 is located in stack of thread T0 at offset 624 in frame #0 0x41f941 in test_vARPRefreshCacheEntry_IPAndMACInDifferentLocations1 (test/unit-test/build/bin/tests/FreeRTOS_ARP_utest+0x41f941) This frame has 2 object(s): [48, 54) 'xMACAddress' (line 1937) [80, 640) 'xEndPoint' (line 1941) <== Memory access at offset 624 is inside this variable Nulling the dangling pointer is enough to fix the test, but in order to keep the 100% line coverage, it must point at somewhere valid. Therefore doing that.
Configuration menu - View commit details
-
Copy full SHA for 7c17cd4 - Browse repository at this point
Copy the full SHA 7c17cd4View commit details -
Configuration menu - View commit details
-
Copy full SHA for 468548e - Browse repository at this point
Copy the full SHA 468548eView commit details -
Configuration menu - View commit details
-
Copy full SHA for a926beb - Browse repository at this point
Copy the full SHA a926bebView commit details -
prvTCPNextTimeout(): Fix leftshift by ~0 encountered in unittest
This expression is obviously undefined when ucRepCount is 0 (leftshift by ~0): 3000U << ( ucRepCount - 1U ) Which is fine if that is impossible. But is it? This case is handled later by clamping the result from 0 to 1 (which hints at how this accidentally works), and this is being tested for (in FreeRTOS_TCP_IP_utest.c:: test_prvTCPNextTimeout_ConnSyn_State_Active_Rep0). I'm also surprised that neither Gcc or Clang optimizes the UB away (which would make the code behave differently with optimization): 1500U << ucRepCount It is very tempting to apply this fix, but 1ms is very different from 1500ms. That may well speak more for lowering the scale factor than making exceptions, though. But not now: For the purpose of fixing sanitizer failures, let's preserve the behaviour for now.
Configuration menu - View commit details
-
Copy full SHA for f4cdff0 - Browse repository at this point
Copy the full SHA f4cdff0View commit details -
Configuration menu - View commit details
-
Copy full SHA for abaea8c - Browse repository at this point
Copy the full SHA abaea8cView commit details -
test_vReceiveRA_vRAProcess(): Fix buffer overflow in test: Don't cast
The struct used as ethernet buffer did not contain the supposed data. The supposed data, however, seems to be correct based on this resource: https://support.huawei.com/enterprise/en/doc/ EDOC1100174721/8ebcb3c3/icmpv6-router-advertisement-ra-message AddressSanitizer called it a buffer overflow just because the buffer happened to be shorter than the supposed data. To make this evident and let type safety prevent this from compiling the wrong way, let's define a struct that contains the right data, and take pointers from the addresses of members instead of casting and doing manual offset calculations as far as possible. Also remove unused variables. I also wonder if the first test is not a subset of the second. It causes a subset of things to happen in the code under test, and their names only differ by a typo.
Configuration menu - View commit details
-
Copy full SHA for d94800a - Browse repository at this point
Copy the full SHA d94800aView commit details -
test_DNS_ParseDNSReply_answer_lmmnr_reply3(): Fix test failure due to…
… use before initialization
Configuration menu - View commit details
-
Copy full SHA for 85bd89c - Browse repository at this point
Copy the full SHA 85bd89cView commit details -
Configuration menu - View commit details
-
Copy full SHA for 42d54ef - Browse repository at this point
Copy the full SHA 42d54efView commit details -
Configuration menu - View commit details
-
Copy full SHA for d839080 - Browse repository at this point
Copy the full SHA d839080View commit details -
unit-test of DHCP option parser: Delete the buffer overflow
Symptom: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffc9dfa5c07 READ of size 1 at 0x7ffc9dfa5c07 thread T0 #0 0x459a49 in prvProcessDHCPReplies test/unit-test/build/Annexed_TCP_Sources/FreeRTOS_DHCP.c:1310 FreeRTOS#1 0x4526d2 in vHandleWaitingAcknowledge test/unit-test/build/Annexed_TCP_Sources/FreeRTOS_DHCP.c:495 FreeRTOS#2 0x4544ef in vDHCPProcessEndPoint test/unit-test/build/Annexed_TCP_Sources/FreeRTOS_DHCP.c:739 FreeRTOS#3 0x43dbd9 in test_vDHCPProcess_eWaitingAcknowledge_DNSIncorrectLength2 (test/unit-test/build/bin/tests/FreeRTOS_DHCP_utest+0x43dbd9) Address 0x7ffc9dfa5c07 is located in stack of thread T0 SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow test/unit-test/build/Annexed_TCP_Sources/FreeRTOS_DHCP.c:1310 in prvProcessDHCPReplies Shadow bytes around the buggy address: 0x7ffc9dfa5980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ffc9dfa5a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ffc9dfa5a80: 00 00 00 00 00 00 00 00 ca ca ca ca 00 00 00 00 0x7ffc9dfa5b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ffc9dfa5b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x7ffc9dfa5c00:[05]cb cb cb cb cb cb cb 00 00 00 00 00 00 00 00 0x7ffc9dfa5c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ffc9dfa5d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ffc9dfa5d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ffc9dfa5e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7ffc9dfa5e80: 00 00 00 00 00 00 00 00 00 00 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 Left alloca redzone: ca Right alloca redzone: cb There were two problems that conspired to create this segfault. The first was allowing the option parser to run off the end of the buffer at all: /* ulGenericLength is incremented by 100 to have uxDNSCount > ipconfigENDPOINT_DNS_ADDRESS_COUNT scenario */ ulGenericLength = sizeof( DHCPMsg ) + 100; The second problem was letting it overshoot the stop byte (0xFF). Which is a problem with having manually updated indexes and length fields. The stop byte was at the end of the buffer, but was of no help, because the buffer length was off by -3 (missing 2 bytes for the opcode and length field of the 6 server addresses and 1 byte to account for an unexplained hole in the serialized stream). The real fix for this kind of fragility is using some helper funcitons for serializing the data while keeping indexes and lenghts consistent (not to mention collapsing repeated lines 8-fold). Anyway, it is trivial to add a check that the serialized stream ends at the end of the buffer (done). Whether to add a functioning stop byte does not matter and should not be needed anymore with such a check. I initially fixed it the wrong way, by keeping it within the same buffer, which hurt line coverage. But what the test wants to test is as commented: At least 6 server addresses, because that's the value of ipconfigENDPOINT_DNS_ADDRESS_COUNT + 1. No "invalid" length required, just an overabundance of DNS servers. As such, let's rename the test. Btw, the test was using a VLA (fixed), and most of the uint32_t writes are still unaligned (I replaced one of them with memcpy).
Configuration menu - View commit details
-
Copy full SHA for dbdf168 - Browse repository at this point
Copy the full SHA dbdf168View commit details -
Configuration menu - View commit details
-
Copy full SHA for 1625765 - Browse repository at this point
Copy the full SHA 1625765View commit details -
FreeRTOS_DNS.c: Fix NULL deref encountered in test_FreeRTOS_gethostby…
…name_SuccessAddressInCache
Configuration menu - View commit details
-
Copy full SHA for df87c35 - Browse repository at this point
Copy the full SHA df87c35View commit details -
FreeRTOS_DNS_Parser_utest: Don't return dangling pointers
UBSan happens to catch this as a misaligned pointer deref within the null page one moment before segfault: source/FreeRTOS_DNS_Parser.c:761:49: runtime error: member access within misaligned address 0x00000000012c for type 'struct freertos_addrinfo', which requires 8 byte alignment This was traced back to the test test_parseDNSAnswer_dns_nocallback_false(), which creates an uninitialized pointer and passes it on. Other tests were also found doing the same, though did not lead to segfault on GCC 12 and 13, except did on GCC 11 in CI with AddressSanitizer. This is a class of error that a higher warning level could easily forbid (reading an uninitialized variable, pointer or not): -Werror=maybe-uninitialized
Configuration menu - View commit details
-
Copy full SHA for 7969ef0 - Browse repository at this point
Copy the full SHA 7969ef0View commit details -
FreeRTOS_DHCP_utest: Fix a read out of bounds
xProcessCheckOption() reads the length from the second byte. So for the purpose of testing reading the second byte, but no more, the buffer length was correctly given as 2, except that the buffer length must then be at least 2.
Configuration menu - View commit details
-
Copy full SHA for 46a6557 - Browse repository at this point
Copy the full SHA 46a6557View commit details -
FreeRTOS_{DNS,Routing}_utest.c: Fix off-by-one buffer overflows
FreeRTOS_DNS_utest.c::test_FreeRTOS_gethostbyname_FailLongAddress: Array length vs index of last element: I was about to add one more byte to the buffer, but it looked like that had been attempted before without remembering to initialize them. Therefore, remove those bytes instead. FreeRTOS_Routing_utest.c::test_pcEndpointName_IPv{4,6}_HappyPath: Can be summed up as sizeof() != strlen(). These tests were copying one byte too many from their test input strings. Non-functional cleanups: * Let input strings have static storage duration (avoid copy to stack). * I found it confusing to take the address of the string constants, as it performs the same pointer decay as doing nothing.
Configuration menu - View commit details
-
Copy full SHA for 37ac5cf - Browse repository at this point
Copy the full SHA 37ac5cfView commit details -
Configuration menu - View commit details
-
Copy full SHA for 2c00d48 - Browse repository at this point
Copy the full SHA 2c00d48View commit details -
FreeRTOS_{DHCPv6,DNS}_utest: Fix memory leaks
Consider undoing this and see if the code under test needs fixing. LeakSanitizer finds these.
Configuration menu - View commit details
-
Copy full SHA for d559aec - Browse repository at this point
Copy the full SHA d559aecView commit details -
Configuration menu - View commit details
-
Copy full SHA for bb80402 - Browse repository at this point
Copy the full SHA bb80402View commit details -
FreeRTOS_TCP_WIN_utest.c: Fix memory leaks of type free(NULL)
The pointer to the allocated memory was reset. ⏚
Configuration menu - View commit details
-
Copy full SHA for ac05ffb - Browse repository at this point
Copy the full SHA ac05ffbView commit details -
FreeRTOS_DHCP_utest: Fix misaligned writing of DHCP option fields
Symptom (UB Sanitizer): Store to misaligned address 0x7ffe* for type 'uint32_t', which requires 4 byte alignment When repeated, these 4-byte fields are 2 bytes apart (because of the option and length bytes). The padding byte added to each test does not solve this problem (consider removing). Should have used memcpy (done). Actually, one thing that makes memcpy tedious is that it takes an address, not a value. I got tired of memcpy halfway through; this is what I mean by helper functions (see the commit about deleting a buffer overflow): The ultimate solution is not memcpy, but helpers that remove those manual indexes and length fields, and with that, the possibility for inconsistencies that can lead to such a buffer overflow.
Configuration menu - View commit details
-
Copy full SHA for 6f64aa8 - Browse repository at this point
Copy the full SHA 6f64aa8View commit details -
FreeRTOS_ND_utest.c: Remove failing but redundant test
test_prvProcessICMPMessage_IPv6_NeighborSolicitationCorrectLen() required these fixes when compiled with -fsanitize=address,memory +usGenerateProtocolChecksum_IgnoreAndReturn( ipCORRECT_CRC ); +vReturnEthernetFrame_ExpectAnyArgs(); … but only this fix when compiled regularly: +usGenerateProtocolChecksum_IgnoreAndReturn( ipCORRECT_CRC ); Thankfully, the intention is clear from the comment. It fails extra with sanitization because the two compared IP addresses actually do compare equal. Which is fixable. But removing the test did not impact coverage.
Configuration menu - View commit details
-
Copy full SHA for dc1a5cb - Browse repository at this point
Copy the full SHA dc1a5cbView commit details -
unit-test: Fix differences between with and without sanitization due …
…to lack of initialization
Configuration menu - View commit details
-
Copy full SHA for 402fd0c - Browse repository at this point
Copy the full SHA 402fd0cView commit details -
Configuration menu - View commit details
-
Copy full SHA for a343be0 - Browse repository at this point
Copy the full SHA a343be0View commit details -
Configuration menu - View commit details
-
Copy full SHA for 10c85d4 - Browse repository at this point
Copy the full SHA 10c85d4View commit details -
CI: Add SANITIZE=address,undefined build
As commented, it had to be a separate build because branch coverage (currently) doesn't ignore artificial branches added by sanitizers. On reusing the same build directory: It's totally possible to use separate build directories in build/, but there is no correctness benefit (CMake rebuilds the object files whose recipe has changed anyway). Rather, CMake saves (130) jobs that don't need to run again when reusing the same build directory. On which builds to build and run first (aubsan before coverage): When it matters, which is when a test is crashing, that's generally when you want to see the AddressSanitizer output.
Configuration menu - View commit details
-
Copy full SHA for 754f495 - Browse repository at this point
Copy the full SHA 754f495View commit details -
FreeRTOS_ND_utest: Don't use an uninitialized ip address
… it's not fun when it only fails in CI. The lookup happened to fail to fail with AddressSanitizer, but only on GCC 11 (not 12 of 13).
Configuration menu - View commit details
-
Copy full SHA for 33d9aba - Browse repository at this point
Copy the full SHA 33d9abaView commit details -
FreeRTOS_DHCP_utest: Fix attempt at making recvfrom return a NULL buffer
With Gcc 11 + AddressSanitizer, the mocked recvfrom would not return a NULL buffer (unlike Gcc 12 and 13 with and without sanitization). A custom stub function gave enough control to do that. The existing FreeRTOS_recvfrom_Generic_NullBuffer() stub did almost the same, but was unused and meaningless (failed to set its out-argument), so it could be replaced.
Configuration menu - View commit details
-
Copy full SHA for 4a08c8a - Browse repository at this point
Copy the full SHA 4a08c8aView commit details -
FreeRTOS_ND_utest: Fix test failures due to missing initialization
test_SendPingRequestIPv6_SendToIP_Pass(): This test segfaulted without AddressSanitizer: 'build/normal/bin/tests/FreeRTOS…' terminated by signal SIGSEGV test_SendPingRequestIPv6_Assert(): ==7143==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/asan/asan_descriptions.cpp:80 "((0 && "Address is not in memory and not in shadow?")) != (0)" (0x0, 0x0) #0 0x7ff6c812f9a8 in AsanCheckFailed ../../../../src/libsanitizer/asan/asan_rtl.cpp:74 FreeRTOS#1 0x7ff6c815032e in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:78 FreeRTOS#2 0x7ff6c809fa77 in GetShadowKind ../../../../src/libsanitizer/asan/asan_descriptions.cpp:80 FreeRTOS#3 0x7ff6c809fa77 in __asan::GetShadowAddressInformation(unsigned long, __asan::ShadowAddressDescription*) ../../../../src/libsanitizer/asan/asan_descriptions.cpp:96 FreeRTOS#4 0x7ff6c809fa77 in __asan::GetShadowAddressInformation(unsigned long, __asan::ShadowAddressDescription*) ../../../../src/libsanitizer/asan/asan_descriptions.cpp:93 FreeRTOS#5 0x7ff6c80a1296 in __asan::AddressDescription::AddressDescription(unsigned long, unsigned long, bool) ../../../../src/libsanitizer/asan/asan_descriptions.cpp:441 FreeRTOS#6 0x7ff6c80a3a84 in __asan::ErrorGeneric::ErrorGeneric(unsigned int, unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long) ../../../../src/libsanitizer/asan/asan_errors.cpp:389 FreeRTOS#7 0x7ff6c812efc5 in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) ../../../../src/libsanitizer/asan/asan_report.cpp:476 FreeRTOS#8 0x7ff6c80abc44 in __interceptor_memset ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:799 FreeRTOS#9 0x55f2e38a3620 in FreeRTOS_SendPingRequestIPv6 build/u22/Annexed_TCP_Sources/FreeRTOS_ND.c:768 FreeRTOS#10 0x55f2e3893053 in test_SendPingRequestIPv6_Assert test/unit-test/FreeRTOS_ND/FreeRTOS_ND_utest.c:1065 FreeRTOS#11 0x55f2e389c5dd in run_test build/u22/FreeRTOS_ND_utest_runner.c:201 FreeRTOS#12 0x55f2e389ca84 in main build/u22/FreeRTOS_ND_utest_runner.c:252 FreeRTOS#13 0x7ff6c6bcbd8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) FreeRTOS#14 0x7ff6c6bcbe3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) FreeRTOS#15 0x55f2e38873d4 in _start (build/u22/bin/tests/FreeRTOS_ND_utest+0x233d4 test_prvProcessICMPMessage_IPv6_NeighborSolicitationNullEP() behaved different with and without ASan on Gcc 11. Without AddressSanitizer on Gcc 11: FreeRTOS_ND_utest.c:1427:test_prvProcessICMPMessage_IPv6_NeighborSolicitationNullEP: FAIL:Function usGenerateProtocolChecksum. Called more times than expected.
Configuration menu - View commit details
-
Copy full SHA for 66e54ed - Browse repository at this point
Copy the full SHA 66e54edView commit details -
test_lTCPWindowTxAdd_nothing_to_do(): Fix TCP window initialization
Under Gcc 11, this expression in the tested function lTCPWindowTxAdd() was always true, leading to imperfect coverage: pxSegment->lDataLength < pxSegment->lMaxLength With Gcc 13, they were both 0. Let's add zero-initialization to make this what's tested for.
Configuration menu - View commit details
-
Copy full SHA for 88a73c4 - Browse repository at this point
Copy the full SHA 88a73c4View commit details
Commits on Jun 8, 2024
-
Configuration menu - View commit details
-
Copy full SHA for 7f92b55 - Browse repository at this point
Copy the full SHA 7f92b55View commit details