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 769727 - Crashes on zero-length files
Crashes on zero-length files
Status: RESOLVED FIXED
Product: libgdata
Classification: Platform
Component: General
git master
Other Linux
: Normal normal
: ---
Assigned To: libgdata-maint
libgdata-maint
Depends on:
Blocks:
 
 
Reported: 2016-08-11 07:10 UTC by Ondrej Holy
Modified: 2016-08-23 10:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
core: Fix crashes on zero-length files (1.45 KB, patch)
2016-08-11 07:11 UTC, Ondrej Holy
committed Details | Review
tests: Add one more test for GDataBuffer (1.90 KB, patch)
2016-08-22 10:28 UTC, Ondrej Holy
none Details | Review
tests: Add one more test for GDataBuffer (1.93 KB, patch)
2016-08-22 12:50 UTC, Ondrej Holy
committed Details | Review
tests: Add one more test for GDataBuffer (2.09 KB, patch)
2016-08-23 06:39 UTC, Ondrej Holy
committed Details | Review

Description Ondrej Holy 2016-08-11 07:10:50 UTC
libgdata crashes on the following abort, when reading zero-length files:

libgdata:ERROR:/home/oholy/gnome/libgdata/gdata/gdata-download-stream.c:572:gdata_download_stream_read: assertion failed: ((reached_eof == FALSE && length_read > 0 && length_read <= (gssize) count && child_error == NULL) || (reached_eof == TRUE && length_read >= 0 && length_read <= (gssize) count && child_error == NULL) || (length_read == -1 && child_error != NULL))

It was originaly reported downstream:
https://bugzilla.redhat.com/show_bug.cgi?id=1364782
Comment 1 Ondrej Holy 2016-08-11 07:11:59 UTC
Created attachment 333089 [details] [review]
core: Fix crashes on zero-length files

reached_eof is set too early and thus it may not be propagated properly in some cases, which may cause abortion when reading zero-length files.
Comment 2 Philip Withnall 2016-08-14 12:45:22 UTC
Review of attachment 333089 [details] [review]:

The patch looks good, but I would prefer to have a unit test for it please. I've just added some basic tests for GDataBuffer (commit f63af42f8ce177dd62ac5c49f6e0219005faaf72) which try to test zero-length files, but I can't reproduce the problem. Could you please update the patch to add an additional test case which reproduces the failure? Thanks!
Comment 3 Philip Withnall 2016-08-14 12:45:22 UTC
Review of attachment 333089 [details] [review]:

The patch looks good, but I would prefer to have a unit test for it please. I've just added some basic tests for GDataBuffer (commit f63af42f8ce177dd62ac5c49f6e0219005faaf72) which try to test zero-length files, but I can't reproduce the problem. Could you please update the patch to add an additional test case which reproduces the failure? Thanks!
Comment 4 Ondrej Holy 2016-08-22 10:28:12 UTC
Created attachment 333897 [details] [review]
tests: Add one more test for GDataBuffer

This test case reproduces the bug...
Comment 5 Philip Withnall 2016-08-22 11:09:33 UTC
Review of attachment 333897 [details] [review]:

Looks good. You could make it faster by using a GCond to synchronise the threads, rather than a timeout.

::: gdata/tests/buffer.c
@@ +81,3 @@
+
+	/* Wait for a while to be sure that gdata_buffer_pop_data has been already called. */
+	g_usleep (G_USEC_PER_SEC / 2);

Use a GCond.

@@ +93,3 @@
+	GDataBuffer *buffer = NULL;  /* owned */
+	gboolean reached_eof = FALSE;
+	guint8 buf[1];

Add a `g_test_bug ("769727");` call here.
Comment 6 Ondrej Holy 2016-08-22 12:50:17 UTC
Created attachment 333901 [details] [review]
tests: Add one more test for GDataBuffer

Ok, I've added g_test_bug call, however I don't know how we can use GCond in this case. gdata_buffer_push_data has to be called after the while loop in gdata_buffer_pop_data is reached, but we can't do anything at this point...
Comment 7 Philip Withnall 2016-08-22 15:37:53 UTC
Review of attachment 333901 [details] [review]:

> gdata_buffer_push_data has to be called after the while loop in
> gdata_buffer_pop_data is reached, but we can't do anything at this point...

Ah, I see. In that case, you’re right; a GCond can’t be used. Can you please add a comment above test_buffer_thread_eof() which explains that the test needs to call push_data() from another thread only once pop_data() has reached its blocking loop. Thanks. OK to commit with that addition.
Comment 8 Ondrej Holy 2016-08-23 06:39:02 UTC
Comment on attachment 333089 [details] [review]
core: Fix crashes on zero-length files

commit 76e12748bd0e519caeeefd6e1ac7ce8086e63059
Comment 9 Ondrej Holy 2016-08-23 06:39:16 UTC
Created attachment 333976 [details] [review]
tests: Add one more test for GDataBuffer

commit 4b29a94a71317ffa9df282fef7f7be126687343a
Comment 10 Philip Withnall 2016-08-23 10:52:31 UTC
Thanks!