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]>
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
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.
|
Please take any Debian-specific discussion to the Debian bug for this crash, https://bugs.debian.org/1082121, to avoid creating extra noise for the upstream libostree maintainers. I've marked some Debian-specific comments here as off-topic to keep them off upstream's radar, but I will reply to them in the Debian bug. |
ostree 2024.4 with curl 8.10.0 do not work, breaking many downstrteam packages; such as flatpaks ostreedev/ostree#3299
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 [smcv: Backport to 2022.7 by using gboolean instead of stdbool.h] Signed-off-by: Simon McVittie <[email protected]> Gbp-Pq: Name curl-Make-socket-callback-during-cleanup-into-no-op.patch
An issue was found during some automated tests, and it was related to OSTree. Looking upstream, there was already an issue opened about this [2], and a fix was recently published [1]. Since this is only available on v2024.9 and were some version behind, we backported this patch. Related-to: TOR-3649 [1] ostreedev/ostree@4d755a8 [2] ostreedev/ostree#3299 Signed-off-by: Eduardo Ferreira <[email protected]>
An issue was found during some automated tests, and it was related to OSTree. Looking upstream, there was already an issue opened about this [2], and a fix was recently published [1]. Since this is only available on v2024.9 and were some version behind, we backported this patch. Related-to: TOR-3649 [1] ostreedev/ostree@4d755a8 [2] ostreedev/ostree#3299 Signed-off-by: Eduardo Ferreira <[email protected]>
An issue was found during some automated tests, and it was related to OSTree. Looking upstream, there was already an issue opened about this [2], and a fix was recently published [1]. Since this is only available on v2024.9 and were some version behind, we backported this patch. Related-to: TOR-3649 [1] ostreedev/ostree@4d755a8 [2] ostreedev/ostree#3299 Signed-off-by: Eduardo Ferreira <[email protected]>
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: