memory corruption when applet struct is changed | developer.brewmp.com memory corruption when applet struct is changed | developer.brewmp.com

Developer

memory corruption when applet struct is changed

Forums:

hi,

i m have an applet structure like the one given below. after building the mod file and copying the executables on the handset device, my application works as per requirements. But when i made changes in the applet structure, actually i increased the array size of the variable in the CData structure (given below), i faced the problem of memory corruption only on the device handset . on the emulator there are no problems at all

that is when i accessing the variable tht are lying before the variable whose array size is changed , there are no issues. but just as i access the changed variable and the variables below it all the memory seems to intermixed.

i think the memory map created for the first time when the application is loaded on the phone doesnt change when i recreate the mod file with changed applet struct...

wht could be the problem... are there any options missing in my mak file becoz of which the changed structure is not mapped properly..

has any1 run into such a prob before.
pls help me out with this prob

struct _mobilefeetonstreetApp
{

AEEApplet a;
IFileMgr * m_pFileMgr;
INetMgr * m_pINetMgr; // Pointer to INetMgr
IStatic * m_pIStatic; // Used for displaying messages
PFNCLEANUP m_pfnViewCleanup;
IHtmlViewer * m_pHTMLViewer;

IMenuCtl* m_Menu; // Main Menu
CData m_CData;
char trans_id[11][51];
;

typedef struct _CData
{
char m_dd3[11][11];
char m_ddNo_3[11][45];
char m_amt_3[11][5];
char m_ret_3[11][11];
char m_res_3[11][150];
char m_add2[11][150];
char m_add3[11][150];

}CData;

Thanks
Pribhi

How can you change its size at runtime????? all the variables in the structure are
constant in size.

How can you change its size at runtime????? all the variables in the structure are
constant in size.

i m not changing any sizes at runtime. i am changing the size in applet structure app.h file through visual studio and compiling the code in the visual studio and then generating the mod file which is copy on the device.
but when i run the application with the new mod file, it gives problems. if i revert then changes and generate the mod file again and then run the application , it runs fine again.
Pribhi

i m not changing any sizes at runtime. i am changing the size in applet structure app.h file through visual studio and compiling the code in the visual studio and then generating the mod file which is copy on the device.
but when i run the application with the new mod file, it gives problems. if i revert then changes and generate the mod file again and then run the application , it runs fine again.
Pribhi

Then it not a problem with the changes you done in the structure of app.h,
The new mod file itself has some error may be its a resource err or something else.
Post your app.....Then we can able to check it.
When you replace a new mod file with old one through cable, some handset requires a reset before running the app. If you don't do this your app will might reset the device and then your app work properly after reset ex: V3C

Then it not a problem with the changes you done in the structure of app.h,
The new mod file itself has some error may be its a resource err or something else.
Post your app.....Then we can able to check it.
When you replace a new mod file with old one through cable, some handset requires a reset before running the app. If you don't do this your app will might reset the device and then your app work properly after reset ex: V3C

hi
Quote:The new mod file itself has some error may be its a resource err or something else.
if there were probs with this resource files, then those wud have come up in the emulator too.. but the code works as desired in the emulator after the size changes in applet structure.
i think i shd redefine my prob... i m not changing the application code, i m only changing the array size of an element in the structure which is defined in the applet structure.
eg:
struct _CtApp
{
AEEApplet a;
// ........... other elements
CData m_CData;
char trans_id[11][51];
;
typedef struct _CData
{
char m_dd3[11][11];
char m_ddNo_3[11][45];
char m_amt_3[11][5];
char m_ret_3[11][11];
char m_res_3[11][150];
char m_add2[11][150];
char m_add3[11][150];
}CData;
the only change i made in my application was tht , i changed the size of m_amt_3[11][5] in the CData structure to m_amt_3[11][21] and CData is defined in my applet structure. Then i rebuilt the mod file and copied it to the device. after which it gave problems. i think the changed structure size was not reflected on the device, becoz the variable values were getting overlapped.
In brew is it that , only for the first time when the device detects a new mif file, the memory map of tht app is decided and brew doesnt change tht map even if a new executables are loaded??
i have observed this prob on diff handsets... so i concluded tht may be thts how brew works... but then.. is there any work around for it...
pls suggest a solution if possible...
Pribhi

hi
Quote:The new mod file itself has some error may be its a resource err or something else.
if there were probs with this resource files, then those wud have come up in the emulator too.. but the code works as desired in the emulator after the size changes in applet structure.
i think i shd redefine my prob... i m not changing the application code, i m only changing the array size of an element in the structure which is defined in the applet structure.
eg:
struct _CtApp
{
AEEApplet a;
// ........... other elements
CData m_CData;
char trans_id[11][51];
;
typedef struct _CData
{
char m_dd3[11][11];
char m_ddNo_3[11][45];
char m_amt_3[11][5];
char m_ret_3[11][11];
char m_res_3[11][150];
char m_add2[11][150];
char m_add3[11][150];
}CData;
the only change i made in my application was tht , i changed the size of m_amt_3[11][5] in the CData structure to m_amt_3[11][21] and CData is defined in my applet structure. Then i rebuilt the mod file and copied it to the device. after which it gave problems. i think the changed structure size was not reflected on the device, becoz the variable values were getting overlapped.
In brew is it that , only for the first time when the device detects a new mif file, the memory map of tht app is decided and brew doesnt change tht map even if a new executables are loaded??
i have observed this prob on diff handsets... so i concluded tht may be thts how brew works... but then.. is there any work around for it...
pls suggest a solution if possible...
Pribhi

Almost all developers do this kind of changes, adding new variables or delete some in their app structure on a daily basis, Only on some Motorola handsets, V3C, K1M has this problem(if you don't reset after loading the mod) but after loading the new mod file and rest the handset you should not have any problem in running the app on any handset.
In BREW, one has to use char pointers than using large arrays...
You app structure "CData" has two many large in fact very huge char arrays, This might causing a problem in your case.
Changing them to pointers will definetely solve your problem....

Almost all developers do this kind of changes, adding new variables or delete some in their app structure on a daily basis, Only on some Motorola handsets, V3C, K1M has this problem(if you don't reset after loading the mod) but after loading the new mod file and rest the handset you should not have any problem in running the app on any handset.
In BREW, one has to use char pointers than using large arrays...
You app structure "CData" has two many large in fact very huge char arrays, This might causing a problem in your case.
Changing them to pointers will definetely solve your problem....

Are you absolutely sure you completely recompiled all of your source files when you built the MOD file?
-Erik

Are you absolutely sure you completely recompiled all of your source files when you built the MOD file?
-Erik

ebrowne wrote:Are you absolutely sure you completely recompiled all of your source files when you built the MOD file?
-Erik
That was my thought too - if the file containing CreateInstance wasn't rebuilt, then it would allocate the old sizeof() not the new one, leading to memory corruption...

ebrowne wrote:Are you absolutely sure you completely recompiled all of your source files when you built the MOD file?
-Erik
That was my thought too - if the file containing CreateInstance wasn't rebuilt, then it would allocate the old sizeof() not the new one, leading to memory corruption...

Brewin wrote:Almost all developers do this kind of changes, adding new variables or delete some in their app structure on a daily basis, Only on some Motorola handsets, V3C, K1M has this problem(if you don't reset after loading the mod) but after loading the new mod file and rest the handset you should not have any problem in running the app on any handset.
In BREW, one has to use char pointers than using large arrays...
Not true. There is an issue with statically initialised multidimensional character arrays on legacy toolchains. Also, you can't stick a large array on the stack due to very limited stack sizes, and therefore do need to use a pointer - but this is data within an AEEApplet subclass. Therefore it's going to be on the heap, not the stack.
Quote:
You app structure "CData" has two many large in fact very huge char arrays, This might causing a problem in your case.
They are just over a kilobyte in size. That's not huge. And not a problem
Quote:
Changing them to pointers will definetely solve your problem....
"Might" or "definitely"? Which is it? In fact, it will solve nothing, and potentially scope for new bugs.

Brewin wrote:Almost all developers do this kind of changes, adding new variables or delete some in their app structure on a daily basis, Only on some Motorola handsets, V3C, K1M has this problem(if you don't reset after loading the mod) but after loading the new mod file and rest the handset you should not have any problem in running the app on any handset.
In BREW, one has to use char pointers than using large arrays...
Not true. There is an issue with statically initialised multidimensional character arrays on legacy toolchains. Also, you can't stick a large array on the stack due to very limited stack sizes, and therefore do need to use a pointer - but this is data within an AEEApplet subclass. Therefore it's going to be on the heap, not the stack.
Quote:
You app structure "CData" has two many large in fact very huge char arrays, This might causing a problem in your case.
They are just over a kilobyte in size. That's not huge. And not a problem
Quote:
Changing them to pointers will definetely solve your problem....
"Might" or "definitely"? Which is it? In fact, it will solve nothing, and potentially scope for new bugs.

BenBlaukopf wrote:Not true. There is an issue with statically initialised multidimensional character arrays on legacy toolchains. Also, you can't stick a large array on the stack due to very limited stack sizes, and therefore do need to use a pointer - but this is data within an AEEApplet subclass. Therefore it's going to be on the heap, not the stack.
I know that the AEEApplet subclass(global variable) is stored on the heap and only function aruguments,local variables and return values are the candidates for stack/registers storage. But when I saw big arrays I feel it was on the stack..(I never given a thought Logically or common sence , bcoz i didn't have any problem like this till date as my debug always starts from AEECreateInstance).
Thanks Ben for pointing it.

BenBlaukopf wrote:Not true. There is an issue with statically initialised multidimensional character arrays on legacy toolchains. Also, you can't stick a large array on the stack due to very limited stack sizes, and therefore do need to use a pointer - but this is data within an AEEApplet subclass. Therefore it's going to be on the heap, not the stack.
I know that the AEEApplet subclass(global variable) is stored on the heap and only function aruguments,local variables and return values are the candidates for stack/registers storage. But when I saw big arrays I feel it was on the stack..(I never given a thought Logically or common sence , bcoz i didn't have any problem like this till date as my debug always starts from AEECreateInstance).
Thanks Ben for pointing it.