GNOME Bugzilla – Bug 750813
libostree raises SIGABRT (core dump) on subsequest pulls after GPG validation failure
Last modified: 2018-08-17 18:58:37 UTC
The version of ostree is built off master: ostree-2015.6.82.gad3a47d-3.fc21.x86_64 The steps to reproduce are as follows. It's important to note that ALL of the steps must be done within a single process. Here is the sequence: 1. Compose a repository or open an existing one. 2. GPG sign the commit associated with a branch. 3. Create a 2nd repository and configure a remote that points the the 1st. 4. Ensure gpg-verify=true 5. Import the WRONG key into the remote specific keyring. 6. Do a PULL on the remote and as expected: GLib.Error('GPG signatures found, but none are in trusted keyring', 'g-io-error-quark', 0) 7. Change the remote gpg-verify=false 8. Do subsequent PULLs on the remote until (usually only takes 2-3): ERROR:src/libostree/ostree-repo-pull.c:808:meta_fetch_on_complete: assertion failed: (pull_data->n_outstanding_metadata_fetches > 0) 9. Observe process killed by SIGABRT. I tried to attach the crash data but might be too large.
Created attachment 305102 [details] trace This is running within the python interpreter using gnome inspection.
I tried reproducing this per your instructions but haven't managed to yet. Until this can be debugged fully maybe the assertion should be softened to a g_return_if_fail() so perhaps the program won't abort.
This is for Pulp right? If you have some Python code to do multiple pulls in one process that can be reduced a bit and not depend on Pulp I can help massage it into a test case for ostree.
I think this may be that we're not cancelling any pending async ops when we hit an error. So an earlier pull process is still queuing sources on the main context, and those get fired on the *next* pull that iterates the context and reads freed memory. This doesn't affect the command line because we exit the process after, and aren't going to iterate the mainloop again before we do. Hum...what we need is a pattern where we can do multiple async ops in parallel, and cancel all of them if any one fail. But we can't just use our own cancellable, we have to (optionally) respect the one the user provided. Yet OTOH we can't cancel theirs, because it may be shared with other tasks. I'm sure there's other code out there that handles this, does it sound right @mbarnes? I haven't actually debugged this, but reading the code it seems most likely.
(In reply to Colin Walters from comment #3) > This is for Pulp right? If you have some Python code to do multiple pulls > in one process that can be reduced a bit and not depend on Pulp I can help > massage it into a test case for ostree. Yes, it is for Pulp. I will attach a pulp independent reproducer.
I don't think there's any stock pattern for this... I would just create a new cancellable, connect to the old cancellable's ::cancelled signal, and cancel the new one if the old one gets cancelled.
(In reply to Dan Winship from comment #6) > I don't think there's any stock pattern for this... I would just create a > new cancellable, connect to the old cancellable's ::cancelled signal, and > cancel the new one if the old one gets cancelled. OstreeFetcher might be a natural place to stash that other GCancellable. Semantics might need more thought, but one possibility is for OstreeFetcher to use its own internal GCancellable if the caller does NOT provide one in an async request, and then introduce either _ostree_fetcher_cancel() or _ostree_fetcher_get_cancellable() to cancel all those pending requests. Then ostree-repo-pull.c would handle actually cancelling the fetcher in response to the other GCancellable's cancelled signal.
Created attachment 305968 [details] [review] Untested patch Untested, but just to illustrate what I had in mind. Not in love with the API semantics. Probably needs more work.
There can be other things that are async besides HTTP requests, such as writing to disk. So I think we need the cancellable in OtPullData.
OSTree has moved to Github a while ago. Furthermore, GNOME Bugzilla will be shut down and replaced by gitlab.gnome.org. If the problem reported in this Bugzilla ticket is still valid, please report it to https://github.com/ostreedev/ostree/issues instead. Thank you! Closing this report as WONTFIX as part of Bugzilla Housekeeping.