Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

for BREW3.1.5
QSC6020 Platform

As I know, calling AEE_FreeMemory will auto close some running Apps. And in BREW Heap Malloc's implementation, when no more RAM to alloc, it will Call AEE_FreeMemory also to free some RAM. and thus maybe some running Apps will be closed.

We catched such case, the log same as below:

MSG Legacy/Error 09:16:57.123 *AEEShell.c 01747 Free Memory (5760107 needed)

Then, several Apps be closed one by one.

Obviously, this may be caused by MALLOC Large Memory. though I can not find who Malloc such large Memory(could you tell me how to find from brew log?), But I think if I remove the AEE_FreeMemory calling in BREW Heap implementation, then this should not happen.

in oemheap3x.c, in AEEkHeap_Realloc, about line2965, chang as below codes:

#if 0
if(AEE_FreeMemory(uSize) == FALSE)
{
{
struct fs_stat fst;
// We check if a specified file exists here or not - if it exists,
// Phone won't err_fatal but just continue
// In other case, we will error fatal.
// This is required to pass OAT UMTS - which requires phone not
// to crash when a large sized memory is tried to be allocated.
if (efs_stat("/brew/shared/mem_fatal_bypass.txt", &fst) < 0 )
{
ERR_FATAL("Malloc failed to allocate memory %d", uSize, 0, 0);
}
}
} // AEE_FreeMemory

#endif

That is, not try to free memory even when no enough RAM to be malloced.

Then, I think the cases"BREW auto close Apps"should never happened.

BUT, when re-try, the same case still happen ,the log almost same as the attached. BREW Still close the Apps.

What is the maater??

When exactly will BREW auto close the apps?
Which Function exactly will lead to auto close Apps?
How to prevent the behaviour completely?

Thanks a lot

I catched it from PKM3.1.5, it seems in BREW3.1.5, For MALLOC implementation, AEE Layer will first check whether the available RAM is enough to malloc(may be use IHeap_CheckAvailable), if Yes, then Call AEEkHeap_Realloc to malloc. if No, Then BREW Will trigger AEE_SCB_LOW_RAM&AEE_SCB_LOW_RAM_CRITICAL System Callback to Let Registered App to free RAM, If No One Registered it, Or though some App registered it, But after triigering Callback, Still no enough RAM meet the request. Then BREW will starting close Apps in fore-ground stack from up to bottom one by one excepted for Top visable App, until the available RAM meet the request. If All Apps except Top-visable App all be closed in fore-ground stack, and still the available RAM not meet the request, Then BREW return NULL for MALLOC, and not Call AEEkHeap_Realloc further.
Hi, Max, Am I Right??
If So, Then How to prevent BREW's such behaviour in BREW3.1.5, from OEM Layer or App Layer. Coz, sometime, our running Apps is more important, and it is not expected to be closed.
Thanks a lot

I catched it from PKM3.1.5, it seems in BREW3.1.5, For MALLOC implementation, AEE Layer will first check whether the available RAM is enough to malloc(may be use IHeap_CheckAvailable), if Yes, then Call AEEkHeap_Realloc to malloc. if No, Then BREW Will trigger AEE_SCB_LOW_RAM&AEE_SCB_LOW_RAM_CRITICAL System Callback to Let Registered App to free RAM, If No One Registered it, Or though some App registered it, But after triigering Callback, Still no enough RAM meet the request. Then BREW will starting close Apps in fore-ground stack from up to bottom one by one excepted for Top visable App, until the available RAM meet the request. If All Apps except Top-visable App all be closed in fore-ground stack, and still the available RAM not meet the request, Then BREW return NULL for MALLOC, and not Call AEEkHeap_Realloc further.
Hi, Max, Am I Right??
If So, Then How to prevent BREW's such behaviour in BREW3.1.5, from OEM Layer or App Layer. Coz, sometime, our running Apps is more important, and it is not expected to be closed.
Thanks a lot

And it is not use even if some App Register these two system callback. Coz maybe the MALLOC request is from other Apps, and the registered App could not Free Extra Resource.
It is better that, if malloc request is un-allowed, directly return NULL, Not do so many auto&hidden things in background!!

And it is not use even if some App Register these two system callback. Coz maybe the MALLOC request is from other Apps, and the registered App could not Free Extra Resource.
It is better that, if malloc request is un-allowed, directly return NULL, Not do so many auto&hidden things in background!!