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

Why was this fork created ? #1

Open
afbjorklund opened this issue Oct 15, 2022 · 12 comments
Open

Why was this fork created ? #1

afbjorklund opened this issue Oct 15, 2022 · 12 comments
Labels
bug Something isn't working

Comments

@afbjorklund
Copy link

It doesn't seem to be compatible with docker-machine or the libmachine driver framework ?
@afbjorklund afbjorklund added the bug Something isn't working label Oct 15, 2022
cfergeau added a commit that referenced this issue Oct 24, 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)
    #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)
    #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)
    #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
@afbjorklund
Copy link
Author

@cfergeau

@cfergeau
Copy link
Collaborator

It was meant to be used in https://github.com/crc-org/vfkit which is in turn used by a machine-driver internal to crc, but it turns out not to be useful for now, this could be removed if this causes confusion.

@afbjorklund
Copy link
Author

Just wondered, the whole machine-drivers organization is something of driftwood...

If you are not going to use it for doing any development, you could archive it perhaps.

@afbjorklund afbjorklund mentioned this issue Aug 11, 2024
Open
@gbraad
Copy link
Member

gbraad commented Oct 8, 2024

Code-Hex#159 (comment)
@AkihiroSuda Seems you also share the same frustrations...

@afbjorklund
Copy link
Author

afbjorklund commented Oct 8, 2024 •
edited
Loading

@gbraad maybe create it ("vz") in the crc-org organization instead, like "vfkit"?

Minikube is still using the libmachine framework, and it now has a vfkit driver...

https://github.com/kubernetes/minikube/tree/master/pkg/drivers/vfkit

@gbraad
Copy link
Member

gbraad commented Oct 8, 2024 •
edited
Loading

we have shared interests among several projects to use

note: this is mostly created for the discussion

@gbraad
Copy link
Member

gbraad commented Oct 8, 2024 •
edited
Loading

I hope you realize that the driver you referenced relies on the built binary that we maintain. the issue is that the swift bindings we use are poorly maintained; the maintainer refuses or ignores requests. this has been ongoing for quite a while and would be detrimental also for the visit driver of minikube if we can't get patches or features included, and/or worked on by multiple people.

https://github.com/kubernetes/minikube/blob/master/pkg%2Fdrivers%2Fvfkit%2Fvfkit.go#L254

@afbjorklund
Copy link
Author

Oh indeed, but as far as I know there are no docker-machine drivers for vz - so the machine-drivers organization is the wrong place for hosting vz. Especially since it is about to be retired? Here was the issue opened for the collaboration:

And it (vfkit) seems to accept submissions just fine, outside of CRC and Podman Desktop :-)

@afbjorklund
Copy link
Author

afbjorklund commented Oct 8, 2024 •
edited
Loading

Also I do think that the original maintainer (of Vz) is looking for funding, in order to start a supporting project for it.

https://github.com/Code-Hex/vz/issues

@afbjorklund
Copy link
Author

The last remaining fork might continue into 2025, but still... The docker-machine drivers are running on life support.

https://gitlab.com/gitlab-org/ci-cd/docker-machine/-/commit/626d13ee78c1845ea22fe27756463b0c2776cb37

@gbraad
Copy link
Member

gbraad commented Oct 8, 2024

vfkit depends on the vz (swift bindings).

@gbraad
Copy link
Member

gbraad commented Oct 8, 2024

funding

money talks, but does not change attitude. Several people in that repo have raised concerns. We are looking for a reliable way to contribute, with likewise-minded people.

machine-drivers might not even be the right place, but a good place to start the discussion until we find a good home.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@gbraad @cfergeau @afbjorklund