CMEM error in encoder version 02.30.00.04

Looks small size memory leak is there in you are setup. I don't think  codec has memory leak. Codec requests cmem pool only during getbuf_info(once per create). Please check other modules for it.

Thanks,

Veeranna

Dear Veeranna,

In my setup, CMEM is used only by the encoder and not by any other module. Hence I feel memory leak in any other module should not affect the CMEM region. Is this understanding correct?

Also I noticed that this error comes always after 32767. Hence I was wondering if this error has something to do with the number of iterations or related to some 16bit signed integer?

Regards,

Kusha

Hi,

Is 32767 iteration means number of frames encoded or number of create and delete? this version encoder gone under lot of testing and many customers are using it. We didn''t see any memory leak in our testbench.

Thanks,

Veeranna

Hi Veeranna,

32767 is the number of create and delete of the encoder instance.

Regards,

Kusha

Hi,

We ran encoder with multiple create and delete. We are not seeing hang after 32767 iteration. We tried this on standalone file based testapp provided with encoder release package.

Thanks,

Veeranna

Hi Veeranna,

Thanks for the prompt reply.

We are trying to run similar test with standalone encoder on our setup. Will tell you the results as soon as we get.

In the meanwhile, can you share the standalone encoder running which is running in the loop.I want to confirm initialization/deinitialization in the loop in my application.

Have you run the test with 100MB or 110MB?

Regards,

Kusha.

We are reading config file each time. For this we just closed the config file before end of while loop and opened it immediately. 

while(foef(confifile))

{

..............

.......

flcose(configfile);

configfile = fopen("configfile" ....);

}

In our test Linux space was 76MB. As you are seeing error in CMEM it should be not be the issue.

Hi Veeranna,

I have a few questions:

1. In your application RMAN_init and other dependent functions related to RMAN specifically, are called once or multiple times? In our application, we are calling these apis multiple times during initialization/de-initialization. Will it lead to any problem?

2. I observed one more thing, if I call "RMAN_exit" multiple times it leads to a segmentation fault in "RMAN_init" in the second iteration itself. What could be the reason? And not calling RMAN_exit, will it lead to any memory leak?

 3. Your CMEM region is 52MB, in our setup it is 18MB. Will this affect the working of standalone application?

May be the number of iterations in your setup has to be increased.

Yesterday, in our test setup we encountered some problem while testing. So, we have run it again. Will let you know the results.

Thanks and Regards,

Kusha

Kusha Kyal said:

1. In your application RMAN_init and other dependent functions related to RMAN specifically, are called once or multiple times? In our application, we are calling these apis multiple times during initialization/de-initialization. Will it lead to any problem?

RMAN init should be only once. 

Kusha Kyal said:

2. I observed one more thing, if I call "RMAN_exit" multiple times it leads to a segmentation fault in "RMAN_init" in the second iteration itself. What could be the reason? And not calling RMAN_exit, will it lead to any memory leak?

segmentation fault should not occur. But you don't need to call RMAN_init/exit multiple times.

Kusha Kyal said:

 3. Your CMEM region is 52MB, in our setup it is 18MB. Will this affect the working of standalone application?

We will try with reduced CMEM, in other way you can check the address you are getting for memtabs for each iteration.

Thanks,

Veeranna

Dear Veeranna,

Our standalone application also ran for approx. 65000 iterations. So, it does not seem to be a problem with the TI library. We are trying to test some more configurations in order to confirm this.

We are using a lot of open source components in our application like gstreamer.

Is it a possibility that the memory leak in these components may affect the CMEM region?

Though, according to my understanding even if there is a leak it will affect only the linux space (110MB) and not CMEM region. Is this correct?

Regards,

Kusha

Hi,

I am not familiar with gstreamer component, so i cant comment on this. From Codec point of view Codec requests the memory(CMEM) and application will allocate it.In you system I dnt know which component will allocates the memory.

Can you check memtabs, inbuf and outbuf addresses for each iteration. 

Thanks,

Hi Veeranna,

I have a query:
Is there a possibility that if there is a leak/memory accumulation in the linux space (110MB), will it affect the CMEM(18MB) region?

I am trying currently to print the memtab, inbuf and outbuf as suggested by you, but till now I have not been able to reproduce this issue.
Are there any other options I can try.

Regards,
Kusha

Hi,

Memory leak in Linux memory should not affect CMEM space. To print the memtabe address you can use codec debug library or run the application with CE_DEBUG=3 debug mode. Ideally addresses of memtabs for each iteration should be same.

Thanks,

Veeranna

Dear Veerana,

We are running our application with memTab debug prints enabled. Up till now it has crossed approx. 10000 iterations, we will let you know the results the moment it crosses 32768 iterations.

Regards,
Kusha

Can you please provide log for any 5 iteraions?

Thanks,

Veeranna

Dear Veeranna,

My application crashed after 32768 iterations.

I observed that there was a change in the addresses of memTab after approx. 32000 iterations.

From the beginning till the 32000 iteration the memTab address is following:
/****************************************************************/
memTab[0].size = 1808 memTab[0].base = 49389000
memTab[1].size = 5744 memTab[1].base = 4938b000
memTab[2].size = 5744 memTab[2].base = 4938d000
memTab[3].size = 20480 memTab[3].base = 4938f000
memTab[4].size = 2048 memTab[4].base = 4939e000
memTab[5].size = 1830912 memTab[5].base = 4df00000
memTab[6].size = 896 memTab[6].base = 493a0000
memTab[7].size = 52188 memTab[7].base = 493a2000
memTab[8].size = 52188 memTab[8].base = 493b1000
memTab[9].size = 65920 memTab[9].base = 493d0000
memTab[10].size = 131072 memTab[10].base = 49427000
memTab[11].size = 262144 memTab[11].base = 4947e000
memTab[12].size = 640 memTab[12].base = 494d5000
memTab[13].size = 49152 memTab[13].base = 494d9000
memTab[14].size = 18304 memTab[14].base = 4954a000
/****************************************************************/

After the 32000 iteration the memTab address changes as following:
/****************************************************************/
memTab[0].size = 1808 memTab[0].base = 49389000
memTab[1].size = 5744 memTab[1].base = 48b89000
memTab[2].size = 5744 memTab[2].base = 48b8b000
memTab[3].size = 20480 memTab[3].base = 48b8d000
memTab[4].size = 2048 memTab[4].base = 48b9c000
memTab[5].size = 1830912 memTab[5].base = 4d100000
memTab[6].size = 896 memTab[6].base = 48b9e000
memTab[7].size = 52188 memTab[7].base = 48ba0000
memTab[8].size = 52188 memTab[8].base = 48baf000
memTab[9].size = 65920 memTab[9].base = 48bce000
memTab[10].size = 131072 memTab[10].base = 48c25000
memTab[11].size = 262144 memTab[11].base = 48c7c000
memTab[12].size = 640 memTab[12].base = 48cd3000
memTab[13].size = 49152 memTab[13].base = 48cd7000
memTab[14].size = 18304 memTab[14].base = 48d48000
/****************************************************************/

Following error prints were seen just before the application crashed:
"CODEC_DEBUG_ENABLE: RMAN initializationCMEMK Error: Failed to find a pool which fits 1830912
 Failed"

1. Is the change in addresses of memTab expected after some amount of iterations? Please suggest.

2. In the standalone application of H264 encoder(which ran for approx. 65000 iterations) and my complete application(which crashed after 32768 iterations), RMAN_exit and RMAN_unregister are not being called. But there is difference in behavior with both application. As mentioned earlier, that if I call RMAN_exit in a loop the standalone application crashes. I want to understand what these two apis do and not calling them will have any affect on the application.

Thanks,
Kusha

Dear Veeranna,

I ran the recording application with RMAN_unregister called for each iteration. The application ran for approx. 64000 iterations without any issues.

1. But I am still not sure why there is a difference of behavior in standalone and my application. Also, what is the effect of not calling RMAN_unregister?

2. If RMAN_exit is called for each iteration in the standalone the application crashes. What is the effect of not calling it and why does the application crash?

Regards,

Kusha

HI 

RMAN related question please create one more thread so that our FC expert can explain.

For memory leak you may have look at 

http://e2e.ti.com/support/embedded/linux/f/354/p/63547/229656.aspx#229656

http://e2e.ti.com/support/embedded/multimedia_software_codecs/f/356/t/89474.aspx?pi199455=2

Hi Veeranna,

In my application, I was not calling RMAN_unregister for each iteration. When I called this my application crashes at 65536 iterations instead of 32768 iterations.

I tried one of the hacks, i.e,  changing in Memory_cmem.c

  if (cb->virtualAddress == virtualAddress &&
            cb->sizeInBytes    == sizeInBytes) {
to
    if (cb->virtualAddress == virtualAddress) {

I recompiled the osal library and used it in my encoder. But still the application crashes after 65536 iterations.

I have a few questions:

1. What could be the relation between the number of iterations(32768-16bit or 65536-32bit) and the crash.

2. I am not sure how to include the changes of DMAI into my application. As the DMAI library, is not used in the H264 encoder present in the dvsdk path dm365_codecs_01_00_06/packages/ti/sdo/codecs/h264enc. Could you please guide me how to proceed with this.

3. Is there anything else I can try at my end?

Regards,
Kusha