App works when BREWLogger runs; without BREWLogger and cable app. resets device. | developer.brewmp.com App works when BREWLogger runs; without BREWLogger and cable app. resets device. | developer.brewmp.com

Developer

App works when BREWLogger runs; without BREWLogger and cable app. resets device.

Forums:

The problem is that the app normally starts only when the device is connected to a PC and debugging messages logged through BREWLogger.
In any other case application immediately reboots the device.
What could be caused by such behavior?

Dmitry V. Zhada wrote:The problem is that the app normally starts only when the device is connected to a PC and debugging messages logged through BREWLogger.
In any other case application immediately reboots the device.
What could be caused by such behavior?
this is the first time i'm reading something like this,
anyways check in ur logger for any memory leaks when u close the application
it may help u to solve ur ptoblem..
And do chk weather same case is hapning with eg appl which has come bundled with sdk.

Dmitry V. Zhada wrote:The problem is that the app normally starts only when the device is connected to a PC and debugging messages logged through BREWLogger.
In any other case application immediately reboots the device.
What could be caused by such behavior?
this is the first time i'm reading something like this,
anyways check in ur logger for any memory leaks when u close the application
it may help u to solve ur ptoblem..
And do chk weather same case is hapning with eg appl which has come bundled with sdk.

Dmitry V. Zhada wrote:The problem is that the app normally starts only when the device is connected to a PC and debugging messages logged through BREWLogger.
In any other case application immediately reboots the device.
What could be caused by such behavior?
In your editor you open up the debugger view and also the output view and run the application.
If its crashing there, then you can identify that there are memory leaks in your application. Debug and remove all those memory leaks, you are good to go.
Application rebooting, generally happens when there is a memory leak as manju explained above

Dmitry V. Zhada wrote:The problem is that the app normally starts only when the device is connected to a PC and debugging messages logged through BREWLogger.
In any other case application immediately reboots the device.
What could be caused by such behavior?
In your editor you open up the debugger view and also the output view and run the application.
If its crashing there, then you can identify that there are memory leaks in your application. Debug and remove all those memory leaks, you are good to go.
Application rebooting, generally happens when there is a memory leak as manju explained above

dumparun wrote:
Application rebooting, generally happens when there is a memory leak as manju explained above
Please excuse me for silence. The bug's reason was that in app I used a reference (&) to an object instead of the pointer(*).
So I don't understand something in references, or ARM ADS 1.2 working with them improperly.
Code was:
void startApp() {
InitializationScreen& screen=InitializationScreen();
m_applet.setCurrentCanvas(screen);
}
Problem solved as follows:
void startApp() {
InitializationScreen *screen=new InitializationScreen();
m_applet.setCurrentCanvas(*screen);
delete screen;

dumparun wrote:
Application rebooting, generally happens when there is a memory leak as manju explained above
Please excuse me for silence. The bug's reason was that in app I used a reference (&) to an object instead of the pointer(*).
So I don't understand something in references, or ARM ADS 1.2 working with them improperly.
Code was:
void startApp() {
InitializationScreen& screen=InitializationScreen();
m_applet.setCurrentCanvas(screen);
}
Problem solved as follows:
void startApp() {
InitializationScreen *screen=new InitializationScreen();
m_applet.setCurrentCanvas(*screen);
delete screen;

I hope you understood the mistake done...
anyways, problem solved... :)
happy coding :)

I hope you understood the mistake done...
anyways, problem solved... :)
happy coding :)

Your original code would have worked, except you were allocating the InitializationScreen on the stack, not the heap. Consequently, once startApp returned, the screen object would have been deleted. As to why it worked with the logger connected - you can put that down to luck.
The advice about memory leaks is wrong - memory leaks don't cause a device reset at application start. They are very unlikely to cause a reset ever, unless you run out of memory and then fail to handle ENOMEMORY.

Your original code would have worked, except you were allocating the InitializationScreen on the stack, not the heap. Consequently, once startApp returned, the screen object would have been deleted. As to why it worked with the logger connected - you can put that down to luck.
The advice about memory leaks is wrong - memory leaks don't cause a device reset at application start. They are very unlikely to cause a reset ever, unless you run out of memory and then fail to handle ENOMEMORY.

BenBlaukopf wrote:
The advice about memory leaks is wrong - memory leaks don't cause a device reset at application start. They are very unlikely to cause a reset ever, unless you run out of memory and then fail to handle ENOMEMORY.
yes ur correct, i was in a diff frame of ref

BenBlaukopf wrote:
The advice about memory leaks is wrong - memory leaks don't cause a device reset at application start. They are very unlikely to cause a reset ever, unless you run out of memory and then fail to handle ENOMEMORY.
yes ur correct, i was in a diff frame of ref