Hi @Julien_B, @muralinagraj.
I’ve encountered something silimar in the past (albeit with my own IPC API interface) where a file descriptor was passed in but wasn’t being closed correctly in the receiver’s address space. See this post.
I think it could be a bug in the PushStream function.
Here’s why:
See the docs on Low-level Messaging API, Sending File Descriptors.
The IPC API will close the original fd in the sender’s address space once it has been sent, so if the sender still needs the fd open on its side, it should duplicate the fd (e.g., using dup() ) before sending it.
This implies that there’s no need to call close(fd) from the application passing it in to le_avdata_PushStream, since the IPC API will take care of that.
However.
On the receiving side, if the fd is not extracted from the message, it will be closed when the message is released. The fd can only be extracted from the message once. Subsequent calls to le_msg_GetFd() will return -1.
The receiving side being the function le_avdata_PushStream. If the fd is extracted, and provided a valid fd is passed in, it should be, the open file descriptor must be explicitly closed in the receiver’s address space.
I think @Julien_B’s patch is needed.
Cheers,
Raf