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


Groups > linux.debian.bugs.dist > #873927

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

From Reiny <hackaria@web.de>
Newsgroups linux.debian.bugs.dist, linux.debian.kernel
Subject Bug#886049: Further splice() tests with and without libglib2.0-0
Date 2018-01-08 00:00 +0100
Message-ID <v5s53-5NG-5@gated-at.bofh.it> (permalink)
References <v3h46-7c-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Cross-posted to 2 groups.

Show all headers | View raw


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.

Back to linux.debian.bugs.dist | Previous | Next | Find similar | Unroll thread


Thread

Bug#886049: Further splice() tests with and without libglib2.0-0 Reiny <hackaria@web.de> - 2018-01-08 00:00 +0100

csiph-web