After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 750813 - libostree raises SIGABRT (core dump) on subsequest pulls after GPG validation failure
libostree raises SIGABRT (core dump) on subsequest pulls after GPG validation...
Status: RESOLVED WONTFIX
Product: ostree
Classification: Infrastructure
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: OSTree maintainer(s)
OSTree maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-06-11 22:25 UTC by Jeff Ortel
Modified: 2018-08-17 18:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
trace (18.37 KB, text/plain)
2015-06-11 22:30 UTC, Jeff Ortel
  Details
Untested patch (6.10 KB, patch)
2015-06-24 02:13 UTC, Matthew Barnes
none Details | Review

Description Jeff Ortel 2015-06-11 22:25:41 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.
Comment 1 Jeff Ortel 2015-06-11 22:30:27 UTC
Created attachment 305102 [details]
trace

This is running within the python interpreter using gnome inspection.
Comment 2 Matthew Barnes 2015-06-14 21:46:41 UTC
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.
Comment 3 Colin Walters 2015-06-19 01:40:29 UTC
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.
Comment 4 Colin Walters 2015-06-19 01:54:14 UTC
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.
Comment 5 Jeff Ortel 2015-06-19 14:36:59 UTC
(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.
Comment 6 Dan Winship 2015-06-19 17:08:59 UTC
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.
Comment 7 Matthew Barnes 2015-06-19 20:42:43 UTC
(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.
Comment 8 Matthew Barnes 2015-06-24 02:13:37 UTC
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.
Comment 9 Colin Walters 2015-06-29 02:31:06 UTC
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.
Comment 10 André Klapper 2018-08-17 18:58:37 UTC
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.