flatpak update produces ostree error with curl 8.10.0 (+ patch)
#3299
Comments
adamthiede
changed the title
flatpak update produces segfault with curl 8.10.0 (+ patch)flatpak update produces ostree error with curl 8.10.0 (+ patch)
|
Hmm fun, thanks for the report. This will require some analysis. If you happen to have the environment set up it'd be quite useful to know if this reproduces with |
|
Sure thing. For reference, here's how Alpine builds ostree: https://git.alpinelinux.org/aports/tree/community/ostree/APKBUILD The "build" step has the configuration options in it. I've built it myself and confirmed that removing the '--with-curl' option does fix this, but I'm unaware of any downsides to that. Attached is the output of |
|
In the error it mentions this line: |
|
The issue has been "fixed" in alpine linux: https://gitlab.alpinelinux.org/alpine/aports/-/issues/16444 All you need to do is downgrade libcurl by doing an |
|
Yes, it's working again, but unless this bug is fixed in curl, then it'll likely be relevant again soon. |
|
It's now relevant in Arch Linux. |
|
I assume "resolving" this in Arch would be similar to Alpine; remove curl as a build dependency in ostree, bump Understandable that that's not a "real" solution. |
|
I have the same problem on archlinux. So i will wait for a fix. This seems to be new problem if this persist i will. Try to remove curl from dependencys But i do not like this solution very much to be honest. |
|
Arch Linux IRC members say this is known and being investigated, so hopefully a fix/workaround is forthcoming. |
|
For now, I've published the |
|
If i this take a lot of time get fix. I will use the AUR package. Thank you very much. @ThatOneCalculator |
|
I just pushed a new release of the ostree package to the Arch [extra] repository built without curl support as a temporary workaround. Updating to @ThatOneCalculator I'm removing your AUR package, it shouldn't be necessary anymore 😉 |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
It would probably be best to keep Arch-specific discussion of mirrors, packages and workarounds to an Arch forum or issue tracker of some sort, to avoid creating noise for the developers who might be able to debug and fix this. The important part of what Arch has done, from an upstream point of view, is: compiling libostree to use libsoup instead of libcurl is a workaround for this. |
|
apologies, i didn't mean for this to get off track. |
I get the same error message with the libcurl 8.10.1 in Debian testing/unstable (the actual library that my libostree is linked to is Unfortunately, libostree's own I'm trying the Flatpak test suite to see whether that reproduces the same error message. |
|
Sorry, the Flatpak test suite doesn't reproduce this either... |
ref ostreedev#3299 This won't fix that issue, but *if* this assertion triggers it should give us a better idea of the possible codepaths where it is happening. Signed-off-by: Colin Walters <[email protected]>
|
Both test suites use a fake-ish HTTP 1 servers (ostree uses |
|
I put up #3306 - it'd be quite useful if someone who is hitting this problem can try running with that patch; again it won't fix the problem but I'm hoping that if that assertion trips we're more likely to get a stack trace that hints at the problem. |
|
That said, if someone affected could get a backtrace that might help a bit. |
Built with the patch, and an attempted install: how would I generate a trace for this? |
This is my best current guess as to the cause of ostreedev#3299 If the fetcher gets torn down while it has outstanding requests in flight, I think we'll end up in some code paths calling into libcurl to cancel things. It might be that prior to the curl change, while the handle was invalid it was "valid enough" for that to work. Clearly moving the multi cleanup to be the last step is a safe thing, and it might fix the bug, so let's do that. Signed-off-by: Colin Walters <[email protected]>
|
I also just put up #3307 which might fix the problem, so if folks could test that too that'd be great |
|
Nice! That's helpful.
Does your system have a core dump collector enabled like systemd's? See https://www.freedesktop.org/software/systemd/man/latest/systemd-coredump.html |
|
With both patches applied: Alpine uses OpenRC; systemd is not present unfortunately. Is there some sort of env variable I can set? |
Please consult your OS's documentation for how to get a useful backtrace from a crash. (It is OS-specific and is not as simple as merely setting an environment variable.) |
I've got this backtrace on arch, if that helps: |
This comment was marked as outdated.
This comment was marked as outdated.
|
Edit sorry...ugh, I may have built with libsoup accidentally when testing the first time; anyways, I have a reproducer environment. |
|
#3307 is updated and fixes this for me. |
|
I've tested and it fixes it for me too. Awesome! I'm building 2024.7 with #3307 and that seems fine. Should I add this patch to the package, or does this warrant a whole release? |
|
We'll be doing an ostree release very soon including this patch, but again to highlight here I think the change is quite safe to cherry-pick. |
|
I believe this is the same issue when updating flatpak on Void linux as well (also with curl and libcurl 8.10.1) |
|
It seems like this should be fixed by #3307. Nice work @cgwalters! |
ref ostreedev/ostree#3299 This won't fix that issue, but *if* this assertion triggers it should give us a better idea of the possible codepaths where it is happening. Signed-off-by: Colin Walters <[email protected]> Origin: upstream, 2024.8, commit:472d9d493a3e4a08415da4c337a7e831e0c5a5e2 Bug-Debian: https://bugs.debian.org/1082121 Gbp-Pq: Name curl-Assert-that-curl_multi_assign-worked.patch
Because curl_multi_cleanup may invoke callbacks, we effectively have some circular references going on here. See discussion in curl/curl#14860 Basically what we do is the socket callback libcurl may invoke into a no-op when we detect we're finalizing. The data structures are owned by this object and not by the callbacks, and will be destroyed below. Note that e.g. g_hash_table_unref() may itself invoke callbacks, which is where some data is cleaned up. Signed-off-by: Colin Walters <[email protected]> Origin: upstream, 2024.8, commit:4d755a85225ea0a02d4580d088bb8a97138cb040 Bug: ostreedev/ostree#3299 Bug-Debian: https://bugs.debian.org/1082121 Gbp-Pq: Name curl-Make-socket-callback-during-cleanup-into-no-op.patch
|
Same issue on Debian Stable (Bookworm) for the past week or so FWIW. |
This should only affect Debian 12 if you are using a newer version of libcurl (upgrading core libraries like this somewhat defeats the purpose of using a stable release). It is a known issue for users of the libcurl 8.10.x in bookworm-backports. The workaround would be to revert to the libcurl 7.88.x shipped in Debian 12. I've uploaded a fixed libostree for Debian 12, but it needs approval by the stable release managers before it will be made available in stable-proposed-updates. |
When running
flatpak updateon Alpine Linux edge, the following error message is produced:This began when this patch was added to Alpine's curl package; the patch addresses this issue and is already in curl's master branch.
Let me know if I can provide any more info.
See here for more info. https://gitlab.alpinelinux.org/alpine/aports/-/issues/16444
The text was updated successfully, but these errors were encountered: