Is this a memory leak or am I misreading what Visual Studio 2017 is showing? - allegro5

I am just learning C++ and figured to use Allegro 5 and Visual Studio 2017 to make a simple 2D game but having written a very simple program that just creates and destroys a window, I am worried that there is a memory leak when so far as I am aware, the code should be fine in this regard.
Hopefully, I just need to understand better what Visual Studio is showing me when running the code via the 'Local Windows Debugger' option.
I'm running the code below via Visual Studio 2017 and the 'Local Windows Debugger' option.
The code runs fine so far as I can see but in the 'Diagnostic Tools' window, looking at Process Memory usage, I am concerned there might be a memory leak.
Here is the code...
#include <iostream>
#include <allegro5/allegro5.h>
int main()
{
std::system ("pause");
al_init();
ALLEGRO_DISPLAY *disp = al_create_display(320, 200);
std::system ("pause");
al_destroy_display(disp);
std::cout << "allegro display has been destroyed...\n";
std::system("pause");
return 0;
}
You'll see I have inserted pauses at various places in the code, and when the code reaches the last Pause, I am expecting Process Memory usage to be the same as when the code was at the first Pause.
Meaning that I am expecting Process Memory usage to be the same at the end of main, as it is at the start, or certainly after al_init();
But what I see is...
Typically the Process Memory shows usage of...
At start of Main... 1.7MB
After al_init();... 1.7MB
After creating display/window... 31.4MB
After al_destroy display/window... 13.8MB
Surely after the window is destroyed/closed I should see Process Memory usage return to 1.7MB?
I created a similarly simply program using OpenGL and see similar behavior albeit with higher Process Memory usage in general.
Hopefully, I just need to understand better what Visual Studio is showing me when running the code via the 'Local Windows Debugger' option.
Thank you for reading....

Related

TestRealTime: How to test a realtime Operating System with Rational Test Real Time

On an AUTOSAR realtime Operating System (OS), the software architecture is layered separately (User space, systemcall interface, kernel space). Also, the switching between user context and kernel context is handled by hardware-specific infrastructure and typically the context switching handler is written in assembly code.
IBM® Rational® Test RealTime v8.0.1 (RTRT) currently treats embedded-assembly-code as mentioned in the below Q&A.
https://www.ibm.com/support/pages/how-treat-embedded-assembly-code ( ** )
RTRT tool using code insertion technololy (technically known as instrumentation process) to insert its own code to measure code coverage of the system under test.
In my case, OS with full pre-emptive design doesn't have the termination points. As the result, OS always runs unless loss of power supply. If there's no work, OS shall be in sleep (normally an idle state and do nothing). If any unexpected errors or exceptions occurs, OS shall be shutdown and run into an infinite loop. These indicated that OS is always running.
I learnt from ( ** ) and ensure context switching working correctly.
But I don't know how to teach RTRT to finish its postprocessing (consisting of attolcov and attolpostpro) in a right way. Note that OS has worked correctly throughout all my tasks already and was confirmed by debugger. SHUTDOWN OS procedure has been executed correctly and OS has been in INFINITE loop (such as while(1){};)
After RTRT ends all its processes, the coverage report of OS module is still empty.
Based on IBM guideline for RTRT
https://www.ibm.com/developerworks/community/forums/atom/download/attachment_14076432_RTRT_User_Guide.pdf?nodeId=de3b0048-968c-4111-897e-b73654af32af
RTRT provides two breakpoints to mark the logging point (priv_writeln) and termination point (priv_close) of its process.
I already tried to drive from INFINITE (my OS) to priv_close (RTRT) by interacting PC register and all Context Switching registers with the Lauterbach debugger but RTRT coverage report was empty even thougth none of errors happened. No error meant that the context switch from kernel space to user space is able to work well and main() function returned correctly.
Solved the problem.
It definitely came from context switching process of Operating System.
In my case, I did a RAM dump to see how user context memory (befor Starting OS) look like.
After that, I will backup all context areas and retore them from Sleep or Infiniteloop in the exact order.
Hereby, RTRT can know the return point and reach its own main() function's _exit to finish report generation progress.
Finally, the code coverage report has been generated.

ARM Eclipse debugging code in the RAM. Is it possible to see the source code`

I have a problem when try to debug the code which is copied to the SRAM and executed from there.
The code is overwriting the data - but it is done only during the system update. The sections where code is placed are correctly defined in the linker script file and the debuger correctly see the addresses. But when I step into the function (and the code in RAM is the correct one) it does not connect the source files with the code executed in the memory.
Do you know how can it be done. Debugging C code on the assembler level is not something which makes me happy :)
Any help appreciated.
The problem is a bit silly. When you call RAM function from the FLASH (the first call has to be done this way) it has to be done by the veneer. It was messing up the debugger. But having own calling macro (because of the distance it has to be done via the pointer) everything works fine
example calling macro.
#define RAMFCALL(func, ...) {unsigned (* volatile fptr)() = (unsigned (* volatile)())func; fptr(__VA_ARGS__);}

STM32H7 - IAR Placing Local Variables into 'Reserved Memory' (0x1FF20000 - 0x1FFFFFFF)

I started a new project using an STM32H7, currently using IAR EWARM V8, used the STM32CUBEMX to generate the configuration code, and get an initial project going.
I worked through a couple of the CUBEMX eval projects to get some hardware verified and working, and am able to step through code fine.
But there is something odd going on, in particular with variables if you assign them as local vars within a function, somehow IAR is placing them into the 'System Reserved' memory range...
ie within 0x1FF20000 - 0x1FFFFFFF
For example... the project example 'FMC_NOR' that STM provides, is test code for testing our a NOR flash, etc..
they created these two small arrays as globals vars just at the top of the main.c file.
(buffer_size is 0x1000)
uint16_t aTxBuffer[BUFFER_SIZE] = {0};
uint16_t aRxBuffer[BUFFER_SIZE] = {0};
When in the global space, they are allocated in the DTCM region (0x2000:0000)
When moved as local vars, they then become allocated into the 'reserved space'...
What happens is, when IAR encounters any arrays like this, the processor faults with an 'imprecise data access' hardware fault.
This same error occurs with code to initialize the JPEG module, as it attempts to load the arrays of Huffman tables, etc...
When using TrueStudio this problem does not occur... CubeMX auto-generates the linker files for whichever compiler you are using.
I didn't specifically see anything in the linker files pointing to the reserved memory address.
So not sure what could be going on? I'm new to using this processor, so I'm just starting to understand it's memory mapping.
Thanks for any help or suggestions, I'd like to get IAR figured out, as so far I like it a bit over TrueStudio.
I solved my own question... so no longer need help on this...
This is in the 'stm32h743xx_flash.icf' generated by STM CUBEMX for the STM32H7...
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 0x400;
define symbol __ICFEDIT_size_heap__ = 0x200;
/**** End of ICF editor section. ###ICF###*/
Bumped the 'size_cstack' up to 2k (0x800) and everything is fine...

My code works in Debug mode, but not in Release mode

I have a code in Visual Studio 2008 in C++ that works with files just by fopen and fclose.
Everything works perfect in Debug mode. and I have tested with several datasets.
But it doesn't work in release mode. It crashes all the time.
I have turned off all the optimizations, also there is no dependency to anything(in the linker), and also I have set these:
Optimization: Disabled(/Od)
Keep Unreferenced Data.
Do Not Remove Redundant
Optimize for Windows98: NO
I still keep wondering how it should not work under these circumstances.
What else should I turn off to let it work as in debug mode?
I think if it works in release mode but not in debug mode, it might be a coding fault but the other way looks weird. isn't it?
I appreciate any help.
--Nima
Debug modes often initialize heap data allocations. The program might be dependent on this behavior. Look for variables and buffers that are not getting initialized.
1) Double check any and all code that depends on preprocessor macros.
2) Use assert() for verify program state preconditions. These must not be expected to impact program flow (ie. removing the check would still allow the code to provide the same end result) because assert is a macro. Use regular run-time conditionals when an assert won't do.
3) Indeed, never leave a variable in an uninitialized state.
By far the most likely explanation is differing undefined behavior in the two modes caused by uninitialized memory. Lack of thread safety and problems with synchronization code can also exhibit this kind of behavior because of differing timing environments between debug and release, but if your program isn't multi-threaded then obviously this can't be it.
I had experienced this and in my case it was because of one of my array of struct which suppose to have only X index, but my looping which check this struct was over checking to X+1 index. Interesting is debugging mode was running fine though I was on Visual C++ 2005.
I spent a few hours by putting in printf into my coding line by line to catch the bug. Anyone has good way to debug this kind of error please let me know.

Why am I getting a buffer overrun error with this line of code?

I only have 1 line of code, and this is:
pcrecpp::RE re("abc");
inside a function OnBnClickedButtonGo(). And this function fails in Release mode, but it works OK in debug mode.
(I am using Visual Studio 8 on Windows XP.)
The error message is:
A buffer overrun has occurred in testregex.exe which has corrupted the program's
internal state. Press Break to debug the program or Continue to terminate
the program.
For more details please see Help topic 'How to debug Buffer Overrun Issues'.
I suspect it is its destructor, which is invisible and implied... but I don't know really.
PS: I am statically linking to the PCRE lib version 7.8.
PS2: Not very relevant, but may help some people who have trouble linking to the PCRE library (it took me hours to sort it out): include the line #define PCRE_STATIC.
I had the same error message in my case. In debug is everything fine, but in release I get the error message. I have a native C/C++ library like native.dll. I have created a mixed unmanaged/managed C++ library, which is a wrapper for that library to .net. Somewhere in this mixed.dll I have an unmanaged function signature declaration, like:
typedef void ( *FunctionOnStartSend)();
for this the I get the message, but if I add a "magic word" there then there is no error message:
typedef void (__stdcall *FunctionOnStartSend)();
If it's happening only in release mode, it's possible that something is getting "optimized" out. Try doing something more than just the one liner, like a Match() and maybe even printing out the matches.
Here is my fresh history:
About a month ago I've got a strange link failure of the VS2008 and that day I dug that setting _SECURE_SCL=0 may help (see link text). And it helped. That day it helped me and I just propagated this setting to all the libs we build at team -- that's because MS says that two libs built with different _SECURE_SCL are incompartible.
Time passed and three days ago I've got a bug when VS2008 says that error message that we see in the first post. And there are no help from the debugger because it overruns only in Release build. I've spend almost 2 days pump'n'jump'n the code of the libs and the overrun was flawed from line to line. Finally I started checking build settings line by line and figured the diff in this setting!
Why, oh why Microsoft guys can't embed some small check in dynamic loader code to test that the library currently running and the one going to be dynamically loaded are incompartible?! Some pice of code that save people's time. Blah!