Skip to content

Conversation

@yashrajsapra
Copy link
Collaborator

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).

Fixes #[Issue]

Description

Precise description of the changes in this pull request

Alternative(s) considered

Have you considered any alternatives? And if so, why have you chosen the approach in this PR?

Type

Type Choose one: (Bug fix | Feature | Documentation | Testing | Other)

Screenshots (if applicable)

Checklist

  • I have read the Contribution Guidelines
  • I have written Unit Tests
  • I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach

@mraduldubey
Copy link
Collaborator

I am reviewing this PR. While reviewing, I looked little deeper into the memory management and it looks like few very risky things are present in the code. They either need to be verified by UT + fix or at least, documented very loudly. This is not a comment on the code changes in this PR. Please await more details.

@mraduldubey
Copy link
Collaborator

We need to put these comments to make sure that no body things its dead code
image

@mraduldubey
Copy link
Collaborator

Another issue is with myOrig.
Currently, its working because FrameFactory::create always calls the Frame::Frame(void *buff, size_t size, boost::shared_ptr<FrameFactory> mother):mutable_buffer(buff,size), myOrig(buff), myMother(mother) that points the myOrig to new memory location given by the HostAllocator::create call in the FrameFactory::create function.
This makes sure that even though myOrig is never reset in the ~Frame - we never get a frame that is pointing to stale memory. But, its a fragile assumption. Also, we use myOrig as a way to make changes to the memory allocated for the frame. We create a new Object Pool slot with older myOrig value but reset the FF::myOrig to NULL to make sure destroy() does not clear the memory at the older object pool slot. This needs to be tested in this PR for behavioral changes.

image

@mraduldubey
Copy link
Collaborator

Another alternative for this is overloading the += operator from the boost:asio:mutable_buffer (which just increments the data pointer) in the Frame class and free the extra chunks there itself. It might be better than the current approach in the time lag between the += and the eventual freeing of the chunks (until destroy() is called).


if (!isOriginal) {
// The pointer has been moved forward by skipBytes
ptrdiff_t offset = static_cast<uint8_t*>(pointer->data()) - static_cast<uint8_t*>(pointer->myOrig);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we need a check for myOrig not being NULL before this. Ideally at the start of the function. There is currently as pathway possible that myOrig is NULL. That check is present at end of this function but the pgm will crash here itself.

auto finalHealth = factory->getPoolHealthRecord();
LOG_INFO << "Final pool health after pointer increment test: " << finalHealth;

tracker.printStats("pointer_increment_leak_test");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not boost assert tracker.hasLeaks() also ?

}

// Test 2: Simulate the skipBytes pointer increment issue
BOOST_AUTO_TEST_CASE(framefactory_pointer_increment_leak_test)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add these tests at "Frame" class level as well

  1. Offsetting from front of frame
  2. Shrinking from end of frame
    You can add them here as well


BOOST_AUTO_TEST_CASE(mp4_reader_memory_leak)
{
std::string videoPath = "./data/Mp4_videos/h264_video_metadata/20230514/0011/1686723796848.mp4";
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this video pushed in the repo? test should be reproducible.


BOOST_AUTO_TEST_CASE(mp4_reader_memory_leak)
{
std::string videoPath = "./data/Mp4_videos/h264_video_metadata/20230514/0011/1686723796848.mp4";
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make sure the video is in repo so that test is reproducible.

LOG_INFO<<"Stopping pipeline";
p->stop();
p->term();
p->wait_for_all();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is the test here ? I dont see any asserts. Please improve this somehow such that manual intervention is not required.

kumaakh and others added 5 commits October 23, 2025 13:59
Filename had \r, made it impossible to checkout on windows
…e see no logs. It is being caused due to this line where we try to log before Logger::initLogger(..) is called.

The application code should make sure that Logger::initLogger(..) is the first line of application. if it is not, then they should make sure that they are only using std::coud and std::cerr for "Early logs".
This should be improved to be a more permanent solution where Logger::initLogger(..) overwrites previous log instances
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants