Languages

Menu
Sites
Language
Media::Player memory management

I was wondering when I used Media::Player::OpenBuffer if it release the buffer memory when I close the player or start a new buffer?

At the moment I keep a pointer to the buffer and release it manually when I stop the player. But I'm getting a rare crash on a consequent OpenBuffer calls on malloc_consolidate and I'm wondering if I'm doing a double delete.

This is a simplified version of my code:

result TizenMediaPlayer::StartAudio()
{
    if (mCurrentByteBuffer != null) {
        AppAssertf(false, "Possible memory leak the buffer should be null");
        delete mCurrentByteBuffer;
    }

    mCurrentByteBuffer = new (std::nothrow) Tizen::Base::ByteBuffer();
    mCurrentByteBuffer->Construct(audioRequest.length);

    tFile.Construct(filename, L"rb");
    tFile.Read(*mCurrentByteBuffer);
    r = mPlayer.OpenBuffer(*mCurrentByteBuffer, false);
    mPlayer.Play();
    ...
}
void TizenMediaPlayer::Stop(void)
{
    PlayerState state = mPlayer.GetState();
    if (state == PLAYER_STATE_PAUSED || state == PLAYER_STATE_PLAYING) {
        mPlayer.Stop();
    }
    state = mPlayer.GetState();
    if (state == PLAYER_STATE_OPENED || state == PLAYER_STATE_ENDOFCLIP || state == PLAYER_STATE_STOPPED) {
        mPlayer.Close();
    }
    if (mCurrentByteBuffer)
    {
        AppLog("Delete Media buffer");
        delete mCurrentByteBuffer;
        mCurrentByteBuffer = null;
   }
   ...
}

As you can see I keep a pointer to mCurrentByteBuffer and then delte it when Stop() is called. Stop() is called by END_OF_FILE callback or if we decide to stop the player for any reason.

The documentation does not cover this topic so any information will help.

Thanks for your help.

Edited by: Stefano Zanetti on 24 Oct, 2013
List

Responses

5 Replies
Stefano Zanetti

I did some memory profiling and looks like that OpenBuffer() allocate a large ammount of memory. Maybe an uncompressed copy of the ByteBuffer?

I tried to delete the ByteBuffer right away after passing it to the Player::OpenBuffer and the player still works. Now I don't know if it is just out of luck (or bad luck) that the memory was not overwriten yet or it's the intended behaviour.

Pushpa G

Hi,

OpenBuffer working : when application calls openBuffer a buffer is created with
ByteBuffer::Costruct(appBuffer), this does not create a whole copy of the buffer but creates a reference to the underlying data. From this you can conclude two things
1. Can i delete the buffer just after OpenBuffer - YES you can, as we increase the reference count of the buffer the buffer is not actually deleted.
2. Does extra memoy allocation happen when we call OpenBuffer - NO, it does not as told above we just create the reference count.

And then,

1. You are thinking that there is extra memory being allowed, can you please give your application and share its results here so that i can analyze (just in the case of OnVideoDecoded callback do we allocate data for uncompressed frames).

2. the buffer being deleted at Stop - again really shouldn't matter, it would be helpful if you can share the application which makes the crash and the call stack of the crash so that i can alalyze on it better

Thank you,

Stefano Zanetti

Hi Pusha,

Thanks for your reply and clarification. So if I'm understanding correctly you are saying that bytebuffer will deleted the memory used once the number of references goes down to zero. 

So in this case I can simply create the buffer in a local variable and let it run. The local variable will decrease the reference once it goes out of scrope and the player whenever it close or start pointing to something else? is this correct? (I'm doing some testing right now with this assumption as we are very tight on our deadline)

This is the top of the call stack of the crash:

Callstack Information (PID:4848)
Call Stack Count: 39
 0: malloc_consolidate + 0x134 (0x40456194) [/lib/libc.so.6] + 0x68194
 1: _int_free + 0x5cc (0x40457a2c) [/lib/libc.so.6] + 0x69a2c
 2: cfree + 0x98 (0x4045b500) [/lib/libc.so.6] + 0x6d500
 3: Tizen::Base::BufferBase::~BufferBase() + 0x22 (0x42d38ca3) [/usr/lib/osp/libosp-appfw.so] + 0x135ca3
 4: Tizen::Base::ByteBuffer::~ByteBuffer() + 0x14 (0x42d38f29) [/usr/lib/osp/libosp-appfw.so] + 0x135f29
 5: Tizen::Base::ByteBuffer::~ByteBuffer() + 0x8 (0x42d38f3d) [/usr/lib/osp/libosp-appfw.so] + 0x135f3d
 6: Tizen::Media::_PlayerImpl::OpenBuffer(Tizen::Base::ByteBuffer const&, bool) + 0x54 (0x4517cd61) [/usr/lib/osp/libosp-media.so.1] + 0x8dd61
 7: Tizen::Media::Player::OpenBuffer(Tizen::Base::ByteBuffer const&, bool) + 0x1e (0x45179e1b) [/usr/lib/osp/libosp-media.so.1] + 0x8ae1b
 8: TizenMediaPlayer::StartAudio() + 0x4b0 (0x447c4818) [/opt/usr/apps/KIokyeoAqK/lib/libinfc.so] + 0x21818
 9: TizenMediaPlayer::step() + 0x4c (0x447c4254) [/opt/usr/apps/KIokyeoAqK/lib/libinfc.so] + 0x21254

In regards of sharing the application. Are you a member of the Tizen support team? how would I go about sharing the app with you?

Thanks,

Stefano

Pushpa G

https://developer.tizen.org/sites/default/files/documentation/testplayer.zip: Here is a sample Application to test openBuffer() memory allocation.
Extra memory allocation doesn't happen when you use openBuffer() and I didnt see any crash when I created buffer using global/local variable.
It works fine in either case.
 

Stefano Zanetti

Hi Pusha,

The simple version I mentioned above seem to be working fine. Before I had a crash every hour of testing now it worked for 2 days of testing before it gave me what seems to be a new type of crash. The call stack seems to be indicating that the issue is in the gstreamer. But I don't think this crash is related to the way I open and use audio buffers.

The code I use now is very simple and look something like this:

result TizenMediaPlayer::StartAudio()
{
    ByteBuffer currentByteBuffer;
    currentByteBuffer.Construct(audioRequest.length);

    tFile.Construct(filename, L"rb");
    tFile.Read(currentByteBuffer);
    r = mPlayer.OpenBuffer(currentByteBuffer, false);
    mPlayer.Play();
    ...
}

This is the call stack of the new crash. Seems some kind of memory corruption that affected GStreamer. Does this error look familiar to you:

Callstack Information (PID:11967)
Call Stack Count: 31
 0: malloc_consolidate + 0x134 (0x40440194) [/lib/libc.so.6] + 0x68194
 1: _int_malloc + 0x7bc (0x40442950) [/lib/libc.so.6] + 0x6a950
 2: __libc_malloc + 0x7c (0x40444dd0) [/lib/libc.so.6] + 0x6cdd0
 3: posix_memalign + 0x5c (0x4044710c) [/lib/libc.so.6] + 0x6f10c
 4: gst_buffer_try_new_and_alloc + 0x1c (0x4452b5f1) [/usr/lib/libgstreamer-0.10.so.0] + 0x245f1
 5: gst_pad_alloc_buffer_full + 0x2be (0x44548497) [/usr/lib/libgstreamer-0.10.so.0] + 0x41497
 6: gst_pad_alloc_buffer + 0x18 (0x4454958d) [/usr/lib/libgstreamer-0.10.so.0] + 0x4258d
 7: gst_base_transform_handle_buffer + 0x118e (0x444e52b7) [/usr/lib/libgstbase-0.10.so.0] + 0x282b7
 8: gst_base_transform_chain + 0x4c (0x444e5645) [/usr/lib/libgstbase-0.10.so.0] + 0x28645
 9: gst_pad_chain_data_unchecked + 0x19e (0x44548abf) [/usr/lib/libgstreamer-0.10.so.0] + 0x41abf
10: gst_pad_push_data + 0x200 (0x44549121) [/usr/lib/libgstreamer-0.10.so.0] + 0x42121
11: gst_pad_push + 0x114 (0x4454b239) [/usr/lib/libgstreamer-0.10.so.0] + 0x44239
12: gst_audiotp_chain + 0x2ee (0x47501e73) [/usr/lib/gstreamer-0.10/libgstaudiotp.so] + 0x1e73
13: gst_pad_chain_data_unchecked + 0x19e (0x44548abf) [/usr/lib/libgstreamer-0.10.so.0] + 0x41abf
14: gst_pad_push_data + 0x200 (0x44549121) [/usr/lib/libgstreamer-0.10.so.0] + 0x42121
15: gst_pad_push + 0x114 (0x4454b239) [/usr/lib/libgstreamer-0.10.so.0] + 0x44239
16: gst_proxy_pad_chain_default + 0x7e (0x4453c00b) [/usr/lib/libgstreamer-0.10.so.0] + 0x3500b
17: gst_pad_chain_data_unchecked + 0x19e (0x44548abf) [/usr/lib/libgstreamer-0.10.so.0] + 0x41abf
18: gst_pad_push_data + 0x200 (0x44549121) [/usr/lib/libgstreamer-0.10.so.0] + 0x42121
19: gst_pad_push + 0x114 (0x4454b239) [/usr/lib/libgstreamer-0.10.so.0] + 0x44239
20: gst_ffmpegdec_frame + 0x269e (0x55a0b1db) [/usr/lib/gstreamer-0.10/libgstffmpeg.so] + 0x2b1db
21: gst_ffmpegdec_chain + 0xa28 (0x55a0dcc1) [/usr/lib/gstreamer-0.10/libgstffmpeg.so] + 0x2dcc1
22: gst_pad_chain_data_unchecked + 0x19e (0x44548abf) [/usr/lib/libgstreamer-0.10.so.0] + 0x41abf
23: gst_pad_push_data + 0x200 (0x44549121) [/usr/lib/libgstreamer-0.10.so.0] + 0x42121
24: gst_pad_push + 0x114 (0x4454b239) [/usr/lib/libgstreamer-0.10.so.0] + 0x44239
25: gst_queue_loop + 0xd0 (0x472a5311) [/usr/lib/gstreamer-0.10/libgstcoreelements.so] + 0x1a311
26: gst_task_func + 0x168 (0x445673d5) [/usr/lib/libgstreamer-0.10.so.0] + 0x603d5
27: default_func + 0x12 (0x44567e8f) [/usr/lib/libgstreamer-0.10.so.0] + 0x60e8f
28: g_thread_pool_thread_proxy + 0x118 (0x40306eb1) [/usr/lib/libglib-2.0.so.0] + 0x51eb1
29: g_thread_proxy + 0x3e (0x4030680f) [/usr/lib/libglib-2.0.so.0] + 0x5180f
30: start_thread + 0xf0 (0x40125b1c) [/lib/libpthread.so.0] + 0x5b1c
End of Call Stack