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.
Reply to: