Will Perone

Tip 1
Make sure you aren't using 'char' types in your code. Char will compile as an int8 in visual studio (unless you specify 'default char unsigned' in Project Settings -> C/C++->Language) but as a uint8 on Arm. This can lead to a number of nebulous errors from typecasting/overflow.

Tip 2
Check that your makefile doesn't have any trailing spaces after the \'s; this will generate pretty obvious compilation errors when building using the makefile.

Tip 3
The flag ALLOC_NO_ZMEM can be or'd in when allocating memory with MALLOC. This will prevent the underlying system from taking time to zero out all the memory allocated. The only way to do this with C++ new though is to overload the definition of it and pass it to the underlying MALLOC call. When doing this watchout for code that implicitly relys on the memory being zeroed out; it will have unpredictable behavior.

Tip 4
When compiling Brew projects, disable exception handeling; it's not needed. Make note that this will cause class constructors to not zero the memory of their member variables upon instantiation.

Tip 5
NSTL will fail your application if it leaks memory. When your application leaks memory in the emulator, upon exit a strange message like the following will appear:
*OEMOS.c:671 - BPOINT Type 1, Node 0x01F74FE4
The best way to handle this is by writing your own memory debugger but in general here's the meanings of the different BPOINT types:
1. Memory leak in the app due to user allocated memory using MALLOC
2. Memory leak in the app due to BREW Interface memory leaks
3. Memory being double freed. Exception
4. Corrupt Node

Tip 6
You can invoke the BREW emulator directly from Visual Studio thus making debugging/running easier. In Visual Studio goto project properties -> Debugging. In the command box enter the exectuable for the BREW emulator (example for 2.x emulator: C:\Program Files\BREW SDK v2.1.3\Bin\BREW_Emulator.exe). Then in the command arguments enter -a (path to your application). Usually the path to your application is where the mif is and one directory under that (named the same as your application) is where the dll/data files reside. You can also specify -d (path to device file) and -m (path to mif). This makes it possible to have multiple build targets where you can actually emulate different devices.

Tip 7
The BREW simulator (emulator) has had a number of weird quirks over time leading to different behavior between versions. Personally I recommend using 3.1.4 but the problem with that is it's not as strict on certain memory related errors as the 3.0.x. You should run your app in 3.0.x at least once to test for minor memory overruns and such. The 3.1.7 emulator is slow as molasses; don't use it.

Shakti 0 0
Your Tips are really helpful. Is there any way to find out the exact location in the source code, of an occurence of BPOINT.

Will 0 0
The best solution I've seen to that is to write your own overloads for allocating / removing memory that take parameters __FILE__ and __LINE__. You can then debug the addresses allocated and crossreference them with the BPOINT addresses that are leaking.

<- for private contact