Fix ASAN related issues #52
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This adds a very basic VirtualMachine unit test which creates a virtual machine with an empty kernel file, and tries to start/pause/resume/requestStop the VM. This causes errors, but the test is useful already to reproduce some issues with the master branch.
This runs the tests after building them with -fsanitize=address. This could help detecting some memory issues in the current code.
There will be compilation warnings for the API only available in newer macOS, but since virtualization_test.go only uses API from macOS 11, we can run it on this OS.
This reintroduces code which was removed in 481c580. The Block_copy/Block_release calls from this helper seem to be needed on my x86_64 macOS11 machine. Without this, example/linux/virtualization segfaults in startWithCompletionHandler. This fixes this ASAN error: ================================================================= ==56003==ERROR: AddressSanitizer: requested allocation size 0x53cb4e83f8b48 (0x53cb4e83f9b48 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T6) #0 0x43f0400 in wrap_malloc+0xa0 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x44400) Code-Hex#1 0x7fff205753ba in _Block_copy+0x5e (libsystem_blocks.dylib:x86_64+0x13ba) Code-Hex#2 0x7fff6f594307 in Base::BlockPtr<void (bool)> Base::BlockPtr<void (bool)>::from_callable<-[VZVirtualMachine startWithCompletionHandler:]::$_13>(-[VZVirtualMachine startWithCompletionHandler:]::$_13)::'lambda'(void*, bool)::__invoke(void*, bool)+0xb37 (Virtualization:x86_64+0x24307) Code-Hex#3 0x43ef5fa in __wrap_dispatch_async_block_invoke+0xca (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x435fa) Code-Hex#4 0x7fff20691622 in _dispatch_call_block_and_release+0xb (libdispatch.dylib:x86_64+0x2622) Code-Hex#5 0x7fff20692805 in _dispatch_client_callout+0x7 (libdispatch.dylib:x86_64+0x3805) Code-Hex#6 0x7fff206985e9 in _dispatch_lane_serial_drain+0x25d (libdispatch.dylib:x86_64+0x95e9) Code-Hex#7 0x7fff206990ac in _dispatch_lane_invoke+0x16d (libdispatch.dylib:x86_64+0xa0ac) Code-Hex#8 0x7fff206a2c0c in _dispatch_workloop_worker_thread+0x32a (libdispatch.dylib:x86_64+0x13c0c) Code-Hex#9 0x7fff2083945c in _pthread_wqthread+0x139 (libsystem_pthread.dylib:x86_64+0x345c) Code-Hex#10 0x7fff2083842e in start_wqthread+0xe (libsystem_pthread.dylib:x86_64+0x242e)
When running example/linux/virtualization with ASAN enabled (sed -i '.bak' 's/FLAGS: /&-fsanitize=address /g' *.go), example/linux/virtualization segfaulted with the backtrace below. This happens because when the '@autoreleasepool' block in `getUUID` ends, it frees the content of the 'const char *ret' variable. 'ret' is then returned and used in go code, which triggers the 'heap-use-after-free' from asan. This commit fixes this bug by calling `strdup` on `ret` before the `@autoreleasepool` block ends. This ensures all objects allocated inside this block are freed as expected, while we keep a copy of the data we are interested in. Then the go code calls `Free` on the uuid when it no longer needs it. This fixes Code-Hex#47 ================================= ==53567==ERROR: AddressSanitizer: heap-use-after-free on address 0x60600002ae11 at pc 0x0000042115b5 bp 0x7ffeefbff7d0 sp 0x7ffeefbfef90 READ of size 37 at 0x60600002ae11 thread T0 #0 0x42115b4 in wrap_strlen+0x184 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x155b4) Code-Hex#1 0x7fff20691598 in _dispatch_strdup_if_mutable+0x11 (libdispatch.dylib:x86_64+0x2598) Code-Hex#2 0x7fff2069750c in _dispatch_lane_create_with_target+0x154 (libdispatch.dylib:x86_64+0x850c) Code-Hex#3 0x40adb5b in _cgo_a012ac8bb423_Cfunc_makeDispatchQueue+0x4b (virtualization:x86_64+0x40adb5b) Code-Hex#4 0x40635e3 in runtime.asmcgocall.abi0+0x63 (virtualization:x86_64+0x40635e3) 0x60600002ae11 is located 17 bytes inside of 64-byte region [0x60600002ae00,0x60600002ae40) freed by thread T0 here: #0 0x4241096 in __sanitizer_mz_free+0x86 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x45096) Code-Hex#1 0x7fff209ffade in _CFRelease+0x478 (CoreFoundation:x86_64h+0x14bade) Code-Hex#2 0x7fff206fa20e in AutoreleasePoolPage::releaseUntil(objc_object**)+0xa6 (libobjc.A.dylib:x86_64h+0x2620e) Code-Hex#3 0x7fff206dce2f in objc_autoreleasePoolPop+0xa0 (libobjc.A.dylib:x86_64h+0x8e2f) Code-Hex#4 0x40ac29e in _cgo_a012ac8bb423_Cfunc_getUUID+0xae (virtualization:x86_64+0x40ac29e) Code-Hex#5 0x40635e3 in runtime.asmcgocall.abi0+0x63 (virtualization:x86_64+0x40635e3) previously allocated by thread T0 here: #0 0x4240dc2 in __sanitizer_mz_calloc+0x92 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x44dc2) Code-Hex#1 0x7fff2067dff3 in _malloc_zone_calloc+0x3a (libsystem_malloc.dylib:x86_64+0x1bff3) Code-Hex#2 0x7fff208b7e61 in _CFRuntimeCreateInstance+0x125 (CoreFoundation:x86_64h+0x3e61) Code-Hex#3 0x7fff208b756b in __CFStringCreateImmutableFunnel3+0x76b (CoreFoundation:x86_64h+0x356b) Code-Hex#4 0x7fff208c3805 in CFStringCreateWithBytes+0x1a (CoreFoundation:x86_64h+0xf805) Code-Hex#5 0x7fff216890bd in +[NSString stringWithUTF8String:]+0x43 (Foundation:x86_64+0x250bd) Code-Hex#6 0x7fff21689ce6 in -[__NSConcreteUUID UUIDString]+0x40 (Foundation:x86_64+0x25ce6) Code-Hex#7 0x40ac26c in _cgo_a012ac8bb423_Cfunc_getUUID+0x7c (virtualization:x86_64+0x40ac26c) Code-Hex#8 0x40635e3 in runtime.asmcgocall.abi0+0x63 (virtualization:x86_64+0x40635e3) SUMMARY: AddressSanitizer: heap-use-after-free (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x155b4) in wrap_strlen+0x184 SIGABRT: abort PC=0x7fff2080d91e m=0 sigcode=0 signal arrived during cgo execution goroutine 1 [syscall]: runtime.cgocall(0x40adb10, 0xc000143d10) /usr/local/Cellar/go/1.18.4/libexec/src/runtime/cgocall.go:157 +0x5c fp=0xc000143ce8 sp=0xc000143cb0 pc=0x40085dc github.com/Code-Hex/vz/v2._Cfunc_makeDispatchQueue(0x60600002ae11) _cgo_gotypes.go:386 +0x49 fp=0xc000143d10 sp=0xc000143ce8 pc=0x40a2189 github.com/Code-Hex/vz/v2.NewVirtualMachine(0x40fd2f0?) /Users/teuf/code/vz/virtualization.go:105 +0x45 fp=0xc000143d88 sp=0xc000143d10 pc=0x40a6a25 main.main() /Users/teuf/code/vz/example/linux/main.go:121 +0x626 fp=0xc000143f80 sp=0xc000143d88 pc=0x40a8306 runtime.main() /usr/local/Cellar/go/1.18.4/libexec/src/runtime/proc.go:250 +0x212 fp=0xc000143fe0 sp=0xc000143f80 pc=0x4038932 runtime.goexit() /usr/local/Cellar/go/1.18.4/libexec/src/runtime/asm_amd64.s:1571 +0x1 fp=0xc000143fe8 sp=0xc000143fe0 pc=0x4063901
|
Close following #46 (comment) |
Repository owner
locked as too heated and limited conversation to collaborators
Sep 23, 2022
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR starts by adding a very basic unit test which reproduces 2 issues, one on macOS 11 on x86_64 machines, and the other one when running with ASAN enabled.
The failing test results can be found at https://github.com/cfergeau/vz/actions/runs/3089765099/jobs/4997751402
After the 2 fixes in the PR, the tests succeed: https://github.com/cfergeau/vz/actions/runs/3089887405/jobs/4998004598