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.

Sign up for GitHub

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

Jump to bottom

Supported MAC Address #7

Merged
merged 5 commits into from
Sep 12, 2021
Merged

Supported MAC Address #7

merged 5 commits into from
Sep 12, 2021

Conversation

Code-Hex
Copy link
Owner

  • I supported to use MAC Address

@Code-Hex Code-Hex merged commit 7475877 into master Sep 12, 2021
@Code-Hex Code-Hex deleted the add/macaddr branch September 12, 2021 15:59
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 10, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
a5714e5 
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)
@cfergeau cfergeau mentioned this pull request Sep 10, 2022
Closed
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 10, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
45b2da1 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 12, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
0e17fce 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 14, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
1528c22 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 19, 2022
@cfergeau
Fix use after free in getUUID()
78bebc2 
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
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 19, 2022
@cfergeau
Fix use after free in getUUID()
7204263 
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
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 20, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
9e5854c 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 20, 2022
@cfergeau
Fix use after free in getUUID()
c5d7854 
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
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 20, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
164a489 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 20, 2022
@cfergeau
Fix use after free in getUUID()
ee3d661 
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
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 20, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
bb57273 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 20, 2022
@cfergeau
Fix use after free in getUUID()
cdf340a 
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
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 21, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
065b5fd 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 21, 2022
@cfergeau
Fix use after free in getUUID()
eae871e 
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
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 21, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
59e98f0 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 21, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
224e6cd 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 21, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
e754d73 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 21, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
4a7b8e6 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 21, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
2f90ba2 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 21, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
b42a47b 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 21, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
69ae1a0 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 21, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
cdd102a 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 21, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
c271960 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 21, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
29905cd 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 21, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
35a0772 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 21, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
735926d 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 22, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
a139fbc 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 22, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
cc5f42b 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 22, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
2b326d9 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 22, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
f932c15 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 22, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
d9b28e8 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 22, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
0c81e0a 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 22, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
f499219 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 22, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
e89971a 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 22, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
12e95ba 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 22, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
5870b94 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 22, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
872fe44 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 22, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
09dbff2 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 22, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
49e1538 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 23, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
932b0aa 
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)

This fixes Code-Hex#50
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 23, 2022
@cfergeau
Fix use after free in getUUID()
4e4a5ce 
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
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 23, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
c55b3d4 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 23, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
dcd1bb1 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Sep 23, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
18e1213 
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)
cfergeau added a commit to cfergeau/vz that referenced this pull request Oct 10, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
70b8f88 
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)

This fixes Code-Hex#50
cfergeau added a commit to cfergeau/vz that referenced this pull request Oct 10, 2022
@cfergeau
Fix use after free in getUUID()
cfc0f4b 
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
cfergeau added a commit to cfergeau/vz that referenced this pull request Oct 11, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
a62b479 
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)

This fixes Code-Hex#50
cfergeau added a commit to cfergeau/vz that referenced this pull request Oct 11, 2022
@cfergeau
Fix use after free in getUUID()
56526d0 
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
cfergeau added a commit to cfergeau/vz that referenced this pull request Oct 11, 2022
@cfergeau
start/pause/stop: Readd 'generateHandler' helper
deb2ca2 
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)

This fixes Code-Hex#50
cfergeau added a commit to cfergeau/vz that referenced this pull request Oct 11, 2022
@cfergeau
Fix use after free in getUUID()
7cac3bc 
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
cfergeau added a commit to cfergeau/vz that referenced this pull request Oct 12, 2022
@cfergeau
Remove autoreleasepool from getUUID()
9024500 
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 removes the autoreleasepool from getUUID() as it's not
needed when using NSUUID.

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
@cfergeau cfergeau mentioned this pull request Oct 12, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@Code-Hex