-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test_generate_gir_with_address_sanitizer
failure
#11754
Comments
This also prevents CI from rebuilding our images. Seems likely to be an underlying glib problem... @xclaesse any idea? |
In this case, PEP 668 was created to allow a thing that Debian wanted, which is for `pip install foobar` to not break the system python. This despite the fact that the system python is fine, unless you use sudo pip which is discouraged for separate reasons, and it is in fact quite natural to install additional packages to the user site-packages. It isn't even the job of the operating system to decide whether the user site-packages is broken, whether the operating system gets the answer correct or not -- it is the job of the operating system to decide whether the operating system is broken, and that can be solved by e.g. enforcing a shebang policy for distribution-packaged software, which distros like Fedora do, and mandating not only that python shebangs do not contain `/usr/bin/env`, but that they *do* contain -s. Anyway, this entire kerfuffle is mostly just a bit of pointless interactive churn, but it bites pretty hard for our use case, which is a container image which is fortunately tested before deployment, so instead of failing to deploy because of theoretical conflicts with the base system (we specifically need base system integration...) we fail to deploy because 5 minutes into pulling apt updates at the very beginning, pip refuses point-blank to work. I especially do not know why it is the job of the operating system to throw errors intended for interactive users at people baking "appliance" containers who cannot "break" the system python anyway. Fix this by doing what Debian and Ubuntu should both have done from the beginning, and opting containers out of this questionable feature entirely. Note that CI images may still not actually complete their build/test cycle and be updated, because e.g. LLVM 16 issues tracked by mesonbuild#11642 or glib ASAN issues tracked by mesonbuild#11754.
@ebassi I bisected glib for this, and GNOME/glib@3b7af4d is the commit that introduced this asan failure. |
So who knows how old the leak is... |
I mean, did you bisect with |
Okay yes that demonstrates the issue as far back as 2.70 at least (I didn't spot check further, just verified that that bisected commit only uncovered a pre-existing issue). |
It would probably be easier if ASan printed out a backtrace, to see which object is getting allocated without getting freed.
That commit appears because the object allocation was switched from the slice allocator to the system one, so anything that was masked by GSlice being opaque to ASan is now visible. |
I'm tried to reproduce this issue, but |
Found that it gets skipped because:
I don't know what that means... |
Oh actually I can reproduce with Ubuntu glib version, it's just the |
I got better backtraces with
|
Here is a fix of the leak in gobject-introspection: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/411. Until that fix reaches our CI distro, we probably need to use the workaround proposed: LSAN_OPTIONS=exitcode=0. |
This makes Meson unit test fail: mesonbuild/meson#11754
It fails with glib >= 2.76 and gobject-introspection <= 1.76.1. Fixes: mesonbuild#11754
It fails with glib >= 2.76 and gobject-introspection <= 1.76.1. Fixes: #11754
It fails with glib >= 2.76 and gobject-introspection <= 1.76.1. Fixes: mesonbuild#11754
Thanks for the upstream fix (I was about to be annoyed enough to do it too :-D), however another trick to get the tests working is compiling with |
It fails with glib >= 2.76 and gobject-introspection <= 1.76.1. Fixes: mesonbuild#11754
This makes Meson unit test fail: mesonbuild/meson#11754
Describe the bug
The
test_generate_gir_with_address_sanitizer
test fails on my machine.Testsuite output
System parameters
meson --version
: 1.1.0-57-g7388737c7ninja --version
: 1.11.1Workaround
Run the testsuite with:
env 'LSAN_OPTIONS=exitcode=0' ./run_unittests.py -v -ktest_generate_gir_with_address_sanitizer
.Tentative patch
The text was updated successfully, but these errors were encountered: