VX6000 Blues | developer.brewmp.com VX6000 Blues | developer.brewmp.com

Developer

VX6000 Blues

Forums:

Okay,

This is a seemingly bizarre situation, no doubt caused by me. But right now, I'm in a jam for time ... and have been hitting my head on the table for the last few hours on this one. I have an app that was seemingly working perfectly fine on 7 handsets. The VX6000 being one of them. Lo and behold on the eve of submitting to NSTL, the publisher wanted a small change. No biggie.

But alas it is. Since it now breaks the VX6000 build. I have isolated the area of code that seems to break it. It is a keyhandling routine that I have. It is rather large, and uses switch statements to parse out the AVK code. It looks something akin the following. I'm giving the basic outline, since it is a very long routine. Granted it is not the best way, but that is how it is done for now.

static boolean keyPressHandler(IApplet* pi, AEEEvent eCode, uint16 wParam, uint32 dwParam)
{
App* app = (App*) pi;
boolean handled = TRUE;
boolean draw;

if(app->suspended)
return FALSE;

switch(app->game_mode)
{
case GM_MAIN_MENU:
switch (wParam)
{
case AVK_POUND:
break;

case AVK_CLR:
break;

default:
break;

}

default:
handled = FALSE;
break;
}

return handled;

The problem I am coming across is that there is one large set of multiple cases essentially like:

case AVK_0:
case AVK_1:
case AVK_2:
case AVK_3:
case AVK_4:
case AVK_5:
case AVK_6:
case AVK_7:
case AVK_8:
case AVK_9:
case AVK_OK:
case AVK_STAR:
case AVK_POUND:
// Do something

default:
// Do the other thing

If I eliminate this case set and always make it "Do the other thing", it works fine.

This seems pretty curious.

I have a couple of questions.

-Is there any issue with using switch statements and the ADS? I know this is a strange question, but I am at my wits end (and riding on little sleep).

-Will there be problems if you have really large functions? I'm not sure just how a BREW phone pages stuff into runtime. Whether it is all just held on the EFS and loaded into program space all at once, or paged in.

Thanks.

Ben

You need to tell us exactly what change you made and how the VX6000 responds -- does the phone crash, freeze, ...?
Does the changed version display any problems on the other handsets when the same code path is executed? Does it work in the Emulator? Is your VX6000 enabled on the network?
I have seen AVK_SELECT many times, but I've never encountered AVK_OK. Where did you find this?
Supply the code in place of // do something.

You need to tell us exactly what change you made and how the VX6000 responds -- does the phone crash, freeze, ...?
Does the changed version display any problems on the other handsets when the same code path is executed? Does it work in the Emulator? Is your VX6000 enabled on the network?
I have seen AVK_SELECT many times, but I've never encountered AVK_OK. Where did you find this?
Supply the code in place of // do something.

Quote:Originally posted by mobileben
case AVK_9:
case AVK_OK:
case AVK_STAR:
case AVK_POUND:
// Do something
default:
// Do the other thing
If I eliminate this case set and always make it "Do the other thing", it works fine.Did you put a break before the default:? All of us miss things like that sometimes. Yeah, Murray is right, use AVK_SELECT instead of AVK_OK. You have to describe the problem with more detail. Is there another programmer you work with who can look at your code?
--t

Quote:Originally posted by mobileben
case AVK_9:
case AVK_OK:
case AVK_STAR:
case AVK_POUND:
// Do something
default:
// Do the other thing
If I eliminate this case set and always make it "Do the other thing", it works fine.Did you put a break before the default:? All of us miss things like that sometimes. Yeah, Murray is right, use AVK_SELECT instead of AVK_OK. You have to describe the problem with more detail. Is there another programmer you work with who can look at your code?
--t

Okay,
Totally, my bad. Thank you lack of sleep. I am using AVK_SELECT. I inserted the OK by mistake because someone kept asking me about the OK key.
The code snippet I added was literally
if (ISHELL_LoadResString(app->a.m_pIShell, STRINGS_RES_FILE, IDS_SPECIALTHANKS0, str, sizeof(str)))
{
IDISPLAY_DrawText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str, -1, getCenterX(IDISPLAY_MeasureText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str), 0, app->screen_w), text_rgn_y, NULL, IDF_TEXT_TRANSPARENT);
text_rgn_y += app->font_normal_h;
if (ISHELL_LoadResString(app->a.m_pIShell, STRINGS_RES_FILE, IDS_SPECIALTHANKS1, str, sizeof(str)))
{
IDISPLAY_DrawText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str, -1, getCenterX(IDISPLAY_MeasureText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str), 0, app->screen_w), text_rgn_y, NULL, IDF_TEXT_TRANSPARENT);
}

Where
AECHAR str[32]; is declared along with AECHAR str1[32].
The largets string being used only 18 characters UNICODE.
The other change was putting in that large switch. I mentioned earlier.
It seems that the combo of adding that large switch and the addition of printing out those two lines of text breaks the program. But only for the VX6000.
Does anyone know if it puts all of the code in RAM prior to running or pages in code on the fly?
Is it possible that adding code somehow puts something out of alignment?
And to answer the details I unfortunately left out previously ....
-I am using ADS 1.2 Eval version. Perhaps I am missing an essential compiler setting?
-The extra text is printed on the opening SPLASH screen
-What happens is the phone resets itself in the main menu. Somewhere along the line, it seems that an image file is getting corrupted, but I am not sure why this would suddenly happen.
-This works no problem on the emulator and on the following phones: VX4400, CDM9500, CDM8600, CDM8900, A530, and T720/T730. Verified on the actual handsets.
-There is a break statement afeter every case region (sorry for leaving that out!).
-The same code path should basically be executed for every phone. The only thing that changes are the math used to center and move things on the screen.
-The do something code is
ISHELL_CancelTimer(app->a.m_pIShell, (PFNNOTIFY) screenOver, (uint32*) pi);
setGameMode(pi, GM_MAIN_MENU);
-I should also add that this code is never run. This is because this code area is used to bypass a screen. It used to be for pressing any key to go immediately to the next screen. I changed it to only respond to certain key presses to be safer for NSTL.
One other thing. I notice that they changed the Resource Editor Version (or so it seems, since the header file out put is slightly different (it appends a _H to the ifdef/define to prevent multiple includes whereas the other version I have on my desktop didn't). Not sure if this could affect it either. I'm remote now on a laptop, so I cannot verify this against the desktop.
And if this wasn't bad enough. The phone is remote right now because I'm off site for another few days. So unfortunately I only have a limited view of what is going on, since I am relying on the testers to tell me what is going on.
Think you can all feel the pain in this situation.
Thanks.
Ben

Okay,
Totally, my bad. Thank you lack of sleep. I am using AVK_SELECT. I inserted the OK by mistake because someone kept asking me about the OK key.
The code snippet I added was literally
if (ISHELL_LoadResString(app->a.m_pIShell, STRINGS_RES_FILE, IDS_SPECIALTHANKS0, str, sizeof(str)))
{
IDISPLAY_DrawText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str, -1, getCenterX(IDISPLAY_MeasureText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str), 0, app->screen_w), text_rgn_y, NULL, IDF_TEXT_TRANSPARENT);
text_rgn_y += app->font_normal_h;
if (ISHELL_LoadResString(app->a.m_pIShell, STRINGS_RES_FILE, IDS_SPECIALTHANKS1, str, sizeof(str)))
{
IDISPLAY_DrawText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str, -1, getCenterX(IDISPLAY_MeasureText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str), 0, app->screen_w), text_rgn_y, NULL, IDF_TEXT_TRANSPARENT);
}

Where
AECHAR str[32]; is declared along with AECHAR str1[32].
The largets string being used only 18 characters UNICODE.
The other change was putting in that large switch. I mentioned earlier.
It seems that the combo of adding that large switch and the addition of printing out those two lines of text breaks the program. But only for the VX6000.
Does anyone know if it puts all of the code in RAM prior to running or pages in code on the fly?
Is it possible that adding code somehow puts something out of alignment?
And to answer the details I unfortunately left out previously ....
-I am using ADS 1.2 Eval version. Perhaps I am missing an essential compiler setting?
-The extra text is printed on the opening SPLASH screen
-What happens is the phone resets itself in the main menu. Somewhere along the line, it seems that an image file is getting corrupted, but I am not sure why this would suddenly happen.
-This works no problem on the emulator and on the following phones: VX4400, CDM9500, CDM8600, CDM8900, A530, and T720/T730. Verified on the actual handsets.
-There is a break statement afeter every case region (sorry for leaving that out!).
-The same code path should basically be executed for every phone. The only thing that changes are the math used to center and move things on the screen.
-The do something code is
ISHELL_CancelTimer(app->a.m_pIShell, (PFNNOTIFY) screenOver, (uint32*) pi);
setGameMode(pi, GM_MAIN_MENU);
-I should also add that this code is never run. This is because this code area is used to bypass a screen. It used to be for pressing any key to go immediately to the next screen. I changed it to only respond to certain key presses to be safer for NSTL.
One other thing. I notice that they changed the Resource Editor Version (or so it seems, since the header file out put is slightly different (it appends a _H to the ifdef/define to prevent multiple includes whereas the other version I have on my desktop didn't). Not sure if this could affect it either. I'm remote now on a laptop, so I cannot verify this against the desktop.
And if this wasn't bad enough. The phone is remote right now because I'm off site for another few days. So unfortunately I only have a limited view of what is going on, since I am relying on the testers to tell me what is going on.
Think you can all feel the pain in this situation.
Thanks.
Ben

I can't seem to find any data cables for the LG VX 6000. How does one use the AppLoader (which needs serial cables) with an LG VX 6000 which appears to only have USB data cables on the market? I am very curious and your help would be appreciated..

I can't seem to find any data cables for the LG VX 6000. How does one use the AppLoader (which needs serial cables) with an LG VX 6000 which appears to only have USB data cables on the market? I am very curious and your help would be appreciated..

Quote:Originally posted by Calin
I can't seem to find any data cables for the LG VX 6000. How does one use the AppLoader (which needs serial cables) with an LG VX 6000 which appears to only have USB data cables on the market? I am very curious and your help would be appreciated..
USB cable works fine. I use the one from FutureDial.

Quote:Originally posted by Calin
I can't seem to find any data cables for the LG VX 6000. How does one use the AppLoader (which needs serial cables) with an LG VX 6000 which appears to only have USB data cables on the market? I am very curious and your help would be appreciated..
USB cable works fine. I use the one from FutureDial.

Ben,
1) What version of the BREW SDK are you using? As I mentioned here, multiple people have told me that compiling with the v1.2 eval using the v2.0 SDK will crash the phone. I believe they all were testing the VX6000.
2) Are making a separate build for the VX6000? What happens if you put a VX4400 client (smaller screen) on the VX6000 handset and run it?
3) I still don't understand the context of the crash. Is this right:
3a) When it's on the splash screen, if you press certain keys then it cancels a timer, and if you press other keys then it prints text?
3b) When you press a key that causes it to print text on the splash screen, then it crashes afterward when the splash screen ends and it displays the main menu?
--t

Ben,
1) What version of the BREW SDK are you using? As I mentioned here, multiple people have told me that compiling with the v1.2 eval using the v2.0 SDK will crash the phone. I believe they all were testing the VX6000.
2) Are making a separate build for the VX6000? What happens if you put a VX4400 client (smaller screen) on the VX6000 handset and run it?
3) I still don't understand the context of the crash. Is this right:
3a) When it's on the splash screen, if you press certain keys then it cancels a timer, and if you press other keys then it prints text?
3b) When you press a key that causes it to print text on the splash screen, then it crashes afterward when the splash screen ends and it displays the main menu?
--t

Ben:
Thanks for the detail. Unfortunately, no root cause jumps out at me. Clearly, it's an issue specific to the VX6000. The only thing I can suggest is track down the specific line of code the phone is choking on then find a workaround. I imagine you already know that the BREW Logger can be used to show output from DBGPRINTF traces embedded in the code. Sorry, other than that, I'm drawing a blank.

Ben:
Thanks for the detail. Unfortunately, no root cause jumps out at me. Clearly, it's an issue specific to the VX6000. The only thing I can suggest is track down the specific line of code the phone is choking on then find a workaround. I imagine you already know that the BREW Logger can be used to show output from DBGPRINTF traces embedded in the code. Sorry, other than that, I'm drawing a blank.

Calin,
1) Click on this:
http://brewforums.qualcomm.com/search.php?query="apploader+vx6000"&searchdate=-1&action=simplesearch
2) You'll see a thread early on the list titled "AppLoader 2.1.1 crashes?" Read it, and use the LG5350 USB drivers. Do NOT use the Verizon Mobile Office Kit VX6000 USB drivers.
3) Go to the BREW Tools Forum. You'll see a sticky thread titled "BREW Tools 2.1.2 Connection Issues". Read it and follow the directions.
You'll then be able to use your VX6000 with a USB cable.
--t

Calin,
1) Click on this:
http://brewforums.qualcomm.com/search.php?query="apploader+vx6000"&searchdate=-1&action=simplesearch
2) You'll see a thread early on the list titled "AppLoader 2.1.1 crashes?" Read it, and use the LG5350 USB drivers. Do NOT use the Verizon Mobile Office Kit VX6000 USB drivers.
3) Go to the BREW Tools Forum. You'll see a sticky thread titled "BREW Tools 2.1.2 Connection Issues". Read it and follow the directions.
You'll then be able to use your VX6000 with a USB cable.
--t

The FutureDial cable for the VX6000 also works well with the FutureDial driver for the VX6000.
http://www.futuredial.com/Products/P_cables.htm
http://www.futuredial.com/support/usbdrivers/Drivers.htm

The FutureDial cable for the VX6000 also works well with the FutureDial driver for the VX6000.
http://www.futuredial.com/Products/P_cables.htm
http://www.futuredial.com/support/usbdrivers/Drivers.htm

Here are some answers to all the great people that have been replying.
Tom:
-I am using SDK1.1. I do actually have the real version of the compiler. The only problem right now is it is half way around the world right now. I'm out of the country and cannot get to it (it was ordered but arrived late). BTW, that is scary that the eval version would have this problem. I would assume that the real copy does not have the problem?
-We use one universal build for everything for all handsets. Well right now it only supports the VX6000, VX4400, T720/T730, CDM9500, CDM8600, CDM8900, A530, and A620.
-When on the splash screen, if you hit a key, it should by pass it. In "theory", it is possible that timing is possible that you would hit a key fast enough to never see the screen. But in normal working operation, the splash screen would display for 2 seconds. If the user wants to bypass, they press any key. The added code was to sort between things like CLR and SEND that we wanted to ignore. The tricky thing is this. We don't press any key in these tests, hence, this code is never run. So we wait out the 2 sec. Then when we get to the main menu and press the direction pad to change the item selected, crash. If i remove the testing (ie. the large switch), then it works. This is why I was asking things about large code sizes, alignment, and maybe anything other that is strange.
Murray:
Thanks. When I get back in the country, I can actually hit up the phone with the DBGPRINTF. Until now, I'm a bit blind, since the testers don't quite know how to do that.
Thanks.
Ben

Here are some answers to all the great people that have been replying.
Tom:
-I am using SDK1.1. I do actually have the real version of the compiler. The only problem right now is it is half way around the world right now. I'm out of the country and cannot get to it (it was ordered but arrived late). BTW, that is scary that the eval version would have this problem. I would assume that the real copy does not have the problem?
-We use one universal build for everything for all handsets. Well right now it only supports the VX6000, VX4400, T720/T730, CDM9500, CDM8600, CDM8900, A530, and A620.
-When on the splash screen, if you hit a key, it should by pass it. In "theory", it is possible that timing is possible that you would hit a key fast enough to never see the screen. But in normal working operation, the splash screen would display for 2 seconds. If the user wants to bypass, they press any key. The added code was to sort between things like CLR and SEND that we wanted to ignore. The tricky thing is this. We don't press any key in these tests, hence, this code is never run. So we wait out the 2 sec. Then when we get to the main menu and press the direction pad to change the item selected, crash. If i remove the testing (ie. the large switch), then it works. This is why I was asking things about large code sizes, alignment, and maybe anything other that is strange.
Murray:
Thanks. When I get back in the country, I can actually hit up the phone with the DBGPRINTF. Until now, I'm a bit blind, since the testers don't quite know how to do that.
Thanks.
Ben

Quote:Originally posted by mobileben
BTW, that is scary that the eval version would have this problem. I would assume that the real copy does not have the problem?Yah, RVCT v1.2 does not have this problem. I thought they were the same compiler, but they make very slightly different sized builds from the same codebase. SDK1.1 should be fine.
Quote:We use one universal build for everything for all handsets. Well right now it only supports the VX6000, VX4400, T720/T730, CDM9500, CDM8600, CDM8900, A530, and A620.Ach. I have actually seen a compiler get confused by nested switch statements, but if the same generated code is running on all handsets, then it's probably not a compiler bug.
Quote:We don't press any key in these tests, hence, this code is never run. So we wait out the 2 sec. Then when we get to the main menu and press the direction pad to change the item selected, crash. If i remove the testing (ie. the large switch), then it works. This is why I was asking things about large code sizes, alignment, and maybe anything other that is strange.So the crash happens when your app->game_mode==GM_MAIN_MENU and you get an AVK_UP or AVK_DOWN? Are you suuuuuure that there's a break after that nested switch statement? (between the mode cases, not just between the key cases) Yeah, it's weird, if you're using an IMenuCtl, then the only reason your code is involved is to pass the up or down event to IMENUCTL_HandleEvent.
Could it be some uninitialized data (e.g. local variable)? Are you using C or C++? What's the warning level on the compilers?
Quote:When I get back in the country, I can actually hit up the phone with the DBGPRINTF.Don't forget that the VX6000 drops a lot of output when DBGPRINTF'ing through the BREWLogger. You might want to make a logging facility that writes to a file. If you flush the log by opening/closing the file on every write, then make sure you don't write too much to the file.
--t

Quote:Originally posted by mobileben
BTW, that is scary that the eval version would have this problem. I would assume that the real copy does not have the problem?Yah, RVCT v1.2 does not have this problem. I thought they were the same compiler, but they make very slightly different sized builds from the same codebase. SDK1.1 should be fine.
Quote:We use one universal build for everything for all handsets. Well right now it only supports the VX6000, VX4400, T720/T730, CDM9500, CDM8600, CDM8900, A530, and A620.Ach. I have actually seen a compiler get confused by nested switch statements, but if the same generated code is running on all handsets, then it's probably not a compiler bug.
Quote:We don't press any key in these tests, hence, this code is never run. So we wait out the 2 sec. Then when we get to the main menu and press the direction pad to change the item selected, crash. If i remove the testing (ie. the large switch), then it works. This is why I was asking things about large code sizes, alignment, and maybe anything other that is strange.So the crash happens when your app->game_mode==GM_MAIN_MENU and you get an AVK_UP or AVK_DOWN? Are you suuuuuure that there's a break after that nested switch statement? (between the mode cases, not just between the key cases) Yeah, it's weird, if you're using an IMenuCtl, then the only reason your code is involved is to pass the up or down event to IMENUCTL_HandleEvent.
Could it be some uninitialized data (e.g. local variable)? Are you using C or C++? What's the warning level on the compilers?
Quote:When I get back in the country, I can actually hit up the phone with the DBGPRINTF.Don't forget that the VX6000 drops a lot of output when DBGPRINTF'ing through the BREWLogger. You might want to make a logging facility that writes to a file. If you flush the log by opening/closing the file on every write, then make sure you don't write too much to the file.
--t

Quote:Don't forget that the VX6000 drops a lot of output when DBGPRINTF'ing through the BREWLogger. You might want to make a logging facility that writes to a file. If you flush the log by opening/closing the file on every write, then make sure you don't write too much to the file.
Oh yeah, I forgot about that. As Tom says, you definitely need to log to a file.

Quote:Don't forget that the VX6000 drops a lot of output when DBGPRINTF'ing through the BREWLogger. You might want to make a logging facility that writes to a file. If you flush the log by opening/closing the file on every write, then make sure you don't write too much to the file.
Oh yeah, I forgot about that. As Tom says, you definitely need to log to a file.

Tom,
I have the compiler jacked on the max warnings (I will also double check this). I double checked:
-ensuring the break statements exists for each case section
-No uninitialized variables
I am using 'C' only. Also, I am not using a menu ctl for this. This is just straight graphic screen with gfx and text that I control.
So, here is the curve ball. I back tracked. And for now, I simply eliminated the huge case statement in question. The problem all originated because I needed to insert two seemingly simply lines of text! This is what I inserted:
if (ISHELL_LoadResString(app->a.m_pIShell, STRINGS_RES_FILE, IDS_SPECIALTHANKS0, str, sizeof(str)))
{
IDISPLAY_DrawText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str, -1, getCenterX(IDISPLAY_MeasureText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str), 0, app->screen_w), text_rgn_y, NULL, IDF_TEXT_TRANSPARENT);
text_rgn_y += app->font_normal_h;
if (ISHELL_LoadResString(app->a.m_pIShell, STRINGS_RES_FILE, IDS_SPECIALTHANKS1, str, sizeof(str)))
{
IDISPLAY_DrawText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str, -1, getCenterX(IDISPLAY_MeasureText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str), 0, app->screen_w), text_rgn_y, NULL, IDF_TEXT_TRANSPARENT);
text_rgn_y += app->font_normal_h;
}

This code now kills the program, in the "same way". This code is from that initial splash screen. Literally if I #if 0/1 that code to turn it on or off, it will either not work or it will.
So, looking over this all, here are the variables I see
-The resource compiler version on my laptop is later than the one on the office one
-ADS Eval version 1.2
-Both the key handling routines and the paint routine (that is where the code snippet is from) are from very large functions
-Perhaps the extra read of the string is affecting the EFS. The code section is displaying several strings that is stored in the BAR file. The newly added text was added at the "end" of the string area. The other text is located together and near each other. So I suppose there could be a weird not reading the data completely problem as well.
I will be home bound soon, and will be able to test the product first hand. So I can let people know if it was (I shudder at this) tester error, the compiler, my dumb mistake, or something else.
But for now, this is a bit perplexing.
Does anyone know how code is run from the BREW? Is it loaded in when needed, or is the whole program loaded into RAM at once?
Thanks.
Ben

Tom,
I have the compiler jacked on the max warnings (I will also double check this). I double checked:
-ensuring the break statements exists for each case section
-No uninitialized variables
I am using 'C' only. Also, I am not using a menu ctl for this. This is just straight graphic screen with gfx and text that I control.
So, here is the curve ball. I back tracked. And for now, I simply eliminated the huge case statement in question. The problem all originated because I needed to insert two seemingly simply lines of text! This is what I inserted:
if (ISHELL_LoadResString(app->a.m_pIShell, STRINGS_RES_FILE, IDS_SPECIALTHANKS0, str, sizeof(str)))
{
IDISPLAY_DrawText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str, -1, getCenterX(IDISPLAY_MeasureText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str), 0, app->screen_w), text_rgn_y, NULL, IDF_TEXT_TRANSPARENT);
text_rgn_y += app->font_normal_h;
if (ISHELL_LoadResString(app->a.m_pIShell, STRINGS_RES_FILE, IDS_SPECIALTHANKS1, str, sizeof(str)))
{
IDISPLAY_DrawText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str, -1, getCenterX(IDISPLAY_MeasureText(app->a.m_pIDisplay, AEE_FONT_NORMAL, str), 0, app->screen_w), text_rgn_y, NULL, IDF_TEXT_TRANSPARENT);
text_rgn_y += app->font_normal_h;
}

This code now kills the program, in the "same way". This code is from that initial splash screen. Literally if I #if 0/1 that code to turn it on or off, it will either not work or it will.
So, looking over this all, here are the variables I see
-The resource compiler version on my laptop is later than the one on the office one
-ADS Eval version 1.2
-Both the key handling routines and the paint routine (that is where the code snippet is from) are from very large functions
-Perhaps the extra read of the string is affecting the EFS. The code section is displaying several strings that is stored in the BAR file. The newly added text was added at the "end" of the string area. The other text is located together and near each other. So I suppose there could be a weird not reading the data completely problem as well.
I will be home bound soon, and will be able to test the product first hand. So I can let people know if it was (I shudder at this) tester error, the compiler, my dumb mistake, or something else.
But for now, this is a bit perplexing.
Does anyone know how code is run from the BREW? Is it loaded in when needed, or is the whole program loaded into RAM at once?
Thanks.
Ben

I am having a similar problem on an LG VX6000 as well. I added a little bit of code to read some AECHAR strings from a resource file, then when I try to print those strings, my program either crashes or the strings contain garbage data.
The SAME codepath on different phones (and on the simulator) doesn't exhibit this broken behavior.
I have isolated the problem to a combination of reading from the resource file and a particular long if/else block (not exactly a switch, but the asm looks similar).
If I only read from the resource file.. I am ok.
If I only have the big if/else if I am ok.
If I do both.. the phone proceeds to become retarded/confused/crashed.
I am at my wit's end. I am beginning to believe this phone is buggy/broken and am getting a replacement. I hope that fixes the problem.
Does anyone else think that if Brew were open-sourced a lot of these problems would not exist? People will spot bad code and point it out... or at least be ablet to more quickly develop work-arounds.
Either that or they should spend WAYYY more money on testing and QA before releasing a new SDK and before implementing BREW for a particular target.
-Calin

I am having a similar problem on an LG VX6000 as well. I added a little bit of code to read some AECHAR strings from a resource file, then when I try to print those strings, my program either crashes or the strings contain garbage data.
The SAME codepath on different phones (and on the simulator) doesn't exhibit this broken behavior.
I have isolated the problem to a combination of reading from the resource file and a particular long if/else block (not exactly a switch, but the asm looks similar).
If I only read from the resource file.. I am ok.
If I only have the big if/else if I am ok.
If I do both.. the phone proceeds to become retarded/confused/crashed.
I am at my wit's end. I am beginning to believe this phone is buggy/broken and am getting a replacement. I hope that fixes the problem.
Does anyone else think that if Brew were open-sourced a lot of these problems would not exist? People will spot bad code and point it out... or at least be ablet to more quickly develop work-arounds.
Either that or they should spend WAYYY more money on testing and QA before releasing a new SDK and before implementing BREW for a particular target.
-Calin

That's pretty strange.
I noticed that the VX6000 is very forgiving about the stack, which leads to symptoms showing up far away from the cause.
For example, I have a debug logging macro that contains a SPRINTF. Another programmer who was working with me was misusing the macro such that the destination string was missing. So all the parameters to SPRINTF were shifted by one, and I guess it was trying to write the output into the const format string. It was not causing a crash, but occasionally I'd see a bit of odd output in the debug log and weird string behavior.
So you might want to search around for any SPRINTF's you use in your code, and make sure they have the proper arguments. The compiler doesn't do syntax or stack checking those on var_arg function calls.
This thread might give you some ideas:
http://brewforums.qualcomm.com/showthread.php?threadid=3177

That's pretty strange.
I noticed that the VX6000 is very forgiving about the stack, which leads to symptoms showing up far away from the cause.
For example, I have a debug logging macro that contains a SPRINTF. Another programmer who was working with me was misusing the macro such that the destination string was missing. So all the parameters to SPRINTF were shifted by one, and I guess it was trying to write the output into the const format string. It was not causing a crash, but occasionally I'd see a bit of odd output in the debug log and weird string behavior.
So you might want to search around for any SPRINTF's you use in your code, and make sure they have the proper arguments. The compiler doesn't do syntax or stack checking those on var_arg function calls.
This thread might give you some ideas:
http://brewforums.qualcomm.com/showthread.php?threadid=3177

Calin,
What compiler are you using, and if the ADS is it the eval? Also , can you give a short code segment. I noticed that when I converted from the eval to the real version, the problem disappeared. But also, what I do now is actually collapse my routines down by calling functions which reduces the size of a routine/switch. Yes, it will increase stack usage, but at the same time, the VX6000 should have a reasonable amount to work with.
Unless of course, like Tom was suggesting ... where VX6000 may have some routines that use the stack poorly like SPRINTF.
I noticed that VX6000 seems to have issues with EFS access, if you do too many reads concurrently without delays.
Ben

Calin,
What compiler are you using, and if the ADS is it the eval? Also , can you give a short code segment. I noticed that when I converted from the eval to the real version, the problem disappeared. But also, what I do now is actually collapse my routines down by calling functions which reduces the size of a routine/switch. Yes, it will increase stack usage, but at the same time, the VX6000 should have a reasonable amount to work with.
Unless of course, like Tom was suggesting ... where VX6000 may have some routines that use the stack poorly like SPRINTF.
I noticed that VX6000 seems to have issues with EFS access, if you do too many reads concurrently without delays.
Ben