I got an error after calling le_avdata_PushStream 218 times. The next call will return LE_FAULT and the following log appears:
Nov 22 08:40:10 swi-mdm9x28 user.warn Legato: -WRN- | avcDaemon[848]/framework T=main | LE_FILENAME unixSocket_ReceiveMsg() 669 | Ancillary data was discarded because it couldn’t fit in our buffer.
Here is my code (the complete sample app that demonstrates this bug is attached here: le_avdata_PushStream.zip (2.6 KB) ):
int fd = open(_filename, O_RDONLY);
le_result_t r = le_avdata_PushStream("Data", fd, _pushCallbackHandler, NULL);
if (r != LE_OK)
{
LE_ERROR("Failed to push stream - fd=%d - %s", fd, LE_RESULT_TXT(r));
_bSessionStarted = false;
}
else
{
LE_DEBUG("PushStream return OK - fd=%d", fd);
_bPublishOnGoing = true;
_u32PushId++;
}
close(fd);
My legato version is: 18.07.0-2
Is it a known limitation?
Any idea to fix or workaround this issue will be appreciated.
I may have found the rootcause and a potential fix for it.
It looked like a memory leakage issue. I added close(fd); at the end of the le_avdata_PushStream function and it looks to work fine now.
Here is the full patch : 0001-le_avdata_PushStream-Close-fd-after-push.patch (678 Bytes)
Can anyone confirm that this fix is valid? Do you see any risk using it?
From the patch you have attached, It says you have added the close(fd) at the end of the le_avdata_PushStream() function in the file apps/platformServices/airVantageConnector/avcDaemon/avData.c.
But from the application(le_avdata_PushStream.zip) you have attached, We see that you have already added close(fd) at the end of the _sampleTimerHandler() function after calling le_avdata_PushStream() function in the file avPublisher.c.
So we don’t think adding close(fd) at the end of the le_avdata_PushStream() has fixed the issue or it was just a coincidence that you didn’t come across the issue(LE_FAULT).
BTW before adding this fix, Issue(LE_FAULT) was seen very frequently ? and how many times did you verify after adding the fix?
Also please provide the information on which module(wp76 or wp77 ?) you are using and firmware release version.
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.
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.