Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #59894 > unrolled thread

Bug#886049: Further splice() tests with and without libglib2.0-0

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#886049: Further splice() tests with and without libglib2.0-0 Reiny <hackaria@web.de> - 2018-01-08 00:00 +0100
    Bug#886049: Further splice() tests with and without libglib2.0-0 Christoph Biedl <debian.axhn@manchmal.in-ulm.de> - 2019-02-13 18:40 +0100

#59894 — Bug#886049: Further splice() tests with and without libglib2.0-0

About the above mentioned bug I did some more tests: I built a debug 
version of the libglib2.0-0 to see what is happening inside where the 
splice function is called. In case of a small file with 112 bytes the 
splice() is called inside the function do_splice() in gfile.c for three 
times:

1. Reading the file into the buffer.

2. Writing the file from the buffer to the destination.

3. Try more reading and abort function if no data was readable --> Here 
the bug appears: The splice call never finishes. The assembly shows that 
the inside behavior is different on the last call. There is a jump to a 
different address.

I tested a simple example program for copying files which is using the 
splice() function (from here: 
https://gist.github.com/karthick18/1234187). This program works normal 
and finishes correctly also with the small file. I modified the program 
structure like inside the libglib2.0-0 so that the splice function is 
called 3 times and added a progress callback. The program works. The 
difference is that it uses normal file descriptors instead of an 
Input-/Output-Stream inside the libglib2.0-0. Using these objects 
together with the splice() seems to cause the deadlock. Maybe there is a 
problem with the streams or GFile objects which directly and indirectly 
are connected to the splice() in libglib2.0-0 since there are many 
helper functions and definitions for their initialization and handling.

As the splice() works with the normal file descriptors it should 
probably not be a kernel problem. Since today the kernel is updated to 
4.14.0-3-amd64 which shows the same behavior.

[toc] | [next] | [standalone]

#63361

[Multipart message — attachments visible in raw view] — view raw

Reiny wrote...

> About the above mentioned bug I did some more tests: I built a debug version
> of the libglib2.0-0 to see what is happening inside where the splice
> function is called. In case of a small file with 112 bytes the splice() is
> called inside the function do_splice() in gfile.c for three times:
(...)

At first, thanks a lot for your analysis.

Now my question, does this still happen in buster or sid? Since I could not
reproduce the problem in buster, but very well in Ubuntu Bionic, I assume
it has been healed the the past weeks, possibly by the latest glib2 upstream
release - although I didn't find anything obvious in the sources.

    Christoph

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web