GNOME Bugzilla – Bug 703464
Runtime check failed: (item->new_api) when sending a chunked request
Last modified: 2018-09-21 16:15:25 UTC
With some testing work I’m doing in libgdata at the moment, I can consistently reproduce the following error in libsoup (e06d243fadb351b63ba6e7734fd1a9b9fccf4d50). I’m sure the way libgdata is (ab)using libsoup is more complex than the bug title makes out, but I don’t have any intuition over what could cause this. This is only reproducible with some local modifications I’ve made to libgdata (such as switching from SoupSessionSync to SoupSession). Let me know if you need to see them. It also requires the patches to bug #703463 and bug #703461 to be applied. Trace: /youtube/upload/simple: [Thread 0x7ffff49b9700 (LWP 6478) exited] [New Thread 0x7ffff49b9700 (LWP 6479)] [New Thread 0x7fffed5f5700 (LWP 6480)] (/opt/gnome3/source/libgdata/gdata/tests/.libs/lt-youtube:6438): libsoup-WARNING **: (soup-session.c:1836):soup_session_process_queue_item: runtime check failed: (item->new_api) Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 0x7fffed5f5700 (LWP 6480)] 0x00007ffff60b12b8 in g_logv (log_domain=0x7ffff73a439f "libsoup", log_level=G_LOG_LEVEL_WARNING, format=0x7ffff6138d28 "%s", args=0x7fffed5f44d8) at gmessages.c:989 989 G_BREAKPOINT (); Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.23-37.fc18.x86_64 keyutils-libs-1.5.5-3.fc18.x86_64 krb5-libs-1.10.3-17.fc18.x86_64 libcom_err-1.42.5-1.fc18.x86_64 libcurl-7.27.0-11.fc18.x86_64 libffi-3.0.10-3.fc18.x86_64 libgcc-4.7.2-8.fc18.x86_64 libidn-1.26-1.fc18.x86_64 liboauth-0.9.7-1.fc18.x86_64 libpng-1.5.13-1.fc18.x86_64 libselinux-2.1.12-7.3.fc18.x86_64 libssh2-1.4.3-2.fc18.x86_64 libtasn1-2.14-1.fc18.x86_64 libxml2-2.9.1-1.fc18.1.x86_64 nspr-4.9.6-1.fc18.x86_64 nss-3.14.3-2.fc18.x86_64 nss-softokn-freebl-3.14.3-1.fc18.x86_64 nss-util-3.14.3-1.fc18.x86_64 openldap-2.4.35-4.fc18.1.x86_64 openssl-libs-1.0.1e-4.fc18.x86_64 pcre-8.31-5.fc18.x86_64 sqlite-3.7.13-2.fc18.x86_64 systemd-libs-201-2.fc18.7.x86_64 xz-libs-5.1.2-2alpha.fc18.x86_64 zlib-1.2.7-9.fc18.x86_64 (gdb) t a a bt
+ Trace 232179
Thread 38 (Thread 0x7fffed5f5700 (LWP 6480))
$1 = {session = 0x69d240, queue = 0x837c40, msg = 0x7fffdc001b90, callback = 0x0, callback_data = 0x0, async_context = 0x0, cancellable = 0x7fffe80120e0, conn = 0x7fffe001c2c0, task = 0x0, io_source = 0x0, paused = 0, new_api = 0, io_started = 0, async = 0, resend_count = 0, state = SOUP_MESSAGE_RUNNING, removed = 0, priority = 2, ref_count = 3, prev = 0x0, next = 0x0, related = 0x0} (gdb) print *item->msg $2 = {parent = {g_type_instance = {g_class = 0x63c750}, ref_count = 8, qdata = 0x8d70e0}, method = 0x425400 "POST", status_code = 0, reason_phrase = 0x0, request_body = 0x64e300, request_headers = 0x7ffff0003580, response_body = 0x7ffff0003540, response_headers = 0x8f6e00} (gdb)
Yeah, I'd need to see the code; control isn't ever supposed to end up at that point when using sync I/O with the old API.
(In reply to comment #1) > Yeah, I'd need to see the code; control isn't ever supposed to end up at that > point when using sync I/O with the old API. I’ve pushed it as the ‘offline-testing’ branch of libgdata. The code in thread 38 of the backtrace in comment #1 is here: https://git.gnome.org/browse/libgdata/tree/gdata/gdata-upload-stream.c?h=offline-testing#n1124 https://git.gnome.org/browse/libgdata/tree/gdata/gdata-service.c?h=offline-testing#n580 And the code in thread 1 is here: https://git.gnome.org/browse/libgdata/tree/gdata/gdata-upload-stream.c?h=offline-testing#n671 I think those are the only 2 relevant files. I realise the code is pretty hairy; it’s been patched up over a number of years, and I haven’t had a chance to sit down and tidy it up re. the recent libsoup changes. Incidental suggestions/criticism/flames are most welcome. If you want to run it, you’ll need the libsoup patches from bug #703463 and bug #703461: jhbuild shell cd gdata/tests sudo ./youtube # the sudo is necessary for the moment; WIP It should then fail in the ‘/youtube/upload/simple’ test.
ok, another problem with implicitly-async-only APIs. In this case, soup-message-io is reaching a point where it has written all of the request body chunks it has, so it pauses the message and returns (to wait for more chunks to be appended), but the sync message code doesn't deal with this correctly.
Is there any more information I can provide? Some of the stuff in my GUADEC talk depends on this working, so let me know what I can do to help get it fixed.
(In reply to comment #4) > Is there any more information I can provide? No, I understand exactly what's happening. > Some of the stuff in my GUADEC > talk depends on this working, so let me know what I can do to help get it > fixed. The fix is non-trivial. Your best bet is to either use an async session, or else to make sure that you never run out of chunks (ie, every time wrote-chunk is emitted, you *must* append another chunk before returning)
(In reply to comment #5) > The fix is non-trivial. Your best bet is to either use an async session, or > else to make sure that you never run out of chunks (ie, every time wrote-chunk > is emitted, you *must* append another chunk before returning) Right. Reverting this commit https://git.gnome.org/browse/libgdata/commit/gdata/gdata-upload-stream.c?id=e795f559327b3f208d768a4461ca1829e0f44693 seems to fix things, by appending another chunk inside every emission of wrote-body-data. Thanks! Do you want to keep the bug open for an eventual fix, or just document it as not permitted?
I've just received a similar issue downstream, at https://bugzilla.redhat.com/show_bug.cgi?id=1030034 but I do not know whether it's exactly this particular issue. Could you have a look, please?
I don't think that's this. This is just a g_warn_if_fail(), whereas you have an actual crash
[mass-moving all "UNCONFIRMED" libsoup bugs to "NEW" after disabling the "UNCONFIRMED" status for this product now that bugzilla.gnome.org allows that. bugspam-libsoup-20150210]
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libsoup/issues/54.