2016 International Conference on Electronic Information Technology and Intellectualization (ICEITI 2016) ISBN: 978-1-60595-364-9
Discussion on Memory Overflow of WINCE
System Customization and EVC Programming
Based on ARM9
He Fu Liu and Qiang Zhao
ABSTRACT
Aiming at the damage of the WINCE memory leakage and the engineering requirement, the embedded system memory leak problem was made in detail. This article contains a lot of configuration info for a CE OS image, which defines the memory blueprint for the CE image. In EVC development program, Dynamic memory allocation and release method has been described, several preventive measures have been listed to prevent GDI memory leak in detail. Finally, we can effectually find and locate the happening of the stack memory leakage, and several preventive measures have been listed to prevent GDI memory leak.
INTRODUCTION
Development of embedded mobile devices based on ARM9 becomes the topic of more and more programmers, indicating that more and more people engaged in the development of the mobile device industry. Of course, there have been all kinds of memory leaks in the development process, these issues are very annoying, and these problems exist in custom system to program source code compilation. Microsoft Windows CE(WINCE)[1] is the customized operating system for embedded devices, but on such a device the memory size is limited, which requires WINCE operating system and programs must strictly control the use of memory. In the program development process, the use of EVC[1] on WINCE programming tool can achieve a variety of functions, but lack all kinds of ________________________
resources for memory leaks unified explanatory information. In this paper, the embedded system memory leak problem was made in detail, and a variety of solutions are proposed. This paper hopes to be able to present a clear understanding of preventing memory leaks to the programmer. The frequently occurring memory leaks are as follows:
WHEN WINCE KERNEL IS COMPILED, THE CONFIGURATION CONFIG.BIV WILL APPEAR “RAM START OVERLAPS ERROR: ROM OVERLAP BINARY" .
If at some point in the development process the OS size becomes larger than system setting range, the compiler will tell you about the problem. In Windows CE 6.0[2], the compiler will fail with a message in the output that says “Error: Ram start overlaps rom binary”. But in previous versions the compiler will simply output a warning message that says “Warning: Image exceeds specified memory size by 14386724 bytes and may not run”. In both cases the compiler will create an nk.bin file, but it will most likely not run on the device.
Windows CE uses.bib files to track, among other things, the memory layout of bootloaders as well as OS images. If you’re writing a new BSP, you’ll definitely need a config.bib file for your OS.
Config.bib - this contains a lot of configuration info for a CE OS image[3]. The memory section is what we’ll focus on – it defines the memory blueprint for the CE image. Here are the important terms:
RAMIMAGE - This is the virtual address region that the kernel and any other components you select for your image will be placed in. This can be RAM or linearly addressable flash.
RAM - This is the virtual address region of RAM that the kernel can allocate to applications and RAM-based file systems[4]. It needs to be virtually contiguous.
RESERVED - These are virtual address regions that are set aside[3]. The CE OS kernel won’t allocate memory in these addresses and components won’t be placed in these addresses.
AUTOSIZE - In the config section, we have the AUTOSIZE=ON (or OFF) variable[4]. If this variable is on, it will treat the RAMIMAGE and RAM regions as a single region, allocating just enough space to hold all of the components to the RAMIMAGE section and making the rest of the space available as RAM. This is a pretty convenient and easy way to make sure you’re getting maximal use out of your RAM space.
In the WINCE provided by the BSP mini2440[4], after analysis, which is found this error, should be because the kernel file is beyond the scope of the 31.5MB, and a condensed version of config.bib (PLATFORM\smdk2440\Files\config.bib)[4]:
MEMORY
RAM 82000000 01E00000 RAM FLASH 92000000 00100000 RESERVED
There are several ways to prevent address memory overflow: 1. Please observe the following modification principle: A. NKSTART+NKLEN<RAMSTART;
B. RAMSTART+RAMLEN<92000000.
NKSTART is NK start address, NKLEN is the length of NK memory, RAMSTART is RAM start address and RANLEN is the length of RAM memory.
2. Allocate more space for the OS
This option is available to you if you have more space available to be allocated. If you require a larger image than the default size of 31MB, you can edit the config bib.h file. Please refer to the RAM build memory map for an explanation on how memory is broken down while WINCE is running. If this is an option for the device, then the nk.bin that was created can be helpful because its size is approximately the size that the OS needs. So if the nk.bin is 32MB, change config.bib to:
NK 80200000 01F00000 RAMIMAGE
But, this change might mean that the RAM allocation must also change or that the starting address of the OS must change, or both. If the OS is in ROM, then other things might need to change as well, like allocation of a flash disk.
3. Reduce the size of the OS
This most likely means removing catalog features that have been added to the OS. Decrease your image size by removing components that are taking up a lot of space. If you have unnecessary features, you can take them out and rebuild your platform[5].
4. Turn on AUTOSIZE
In the bib file CONFIG section set AUTOSIZE=ON. This tells the image file to automatically adjust the RAMIMAGE and RAM memory space.
5. Change the hardware
This option is usually required to change the hardware structure, but you could add more RAM or ROM space to the system.
MALLOC, NEW, FREE AND DELETE OPERATIONS ARE IMPROPERLY USED TO CAUSE MEMORY LEAKS.
considered as a malloc operation plus a constructor execution, which is just a pointer to the new operation that is generated by the program.
When using malloc or new operations for memory and free memory or delete operation to release memory, common errors and countermeasures are as follows:
1. To allocate memory using malloc is not successful in the program source code, but to use it. Novice programmers often make this mistake, common solution is: if you are using malloc or new to allocate memory, it is used for anti-error process whether this pointer variable is a null value. Although we allocate memory using malloc operating successfully, but the memory have not yet been initialized, resulting in a reference to the initial value of the error (such as arrays). This error has two main reasons: First, there is no concept of initialization, the second is the misconception that the whole memory of the default initial value is zero.
2. Programming is banned from continuously twice free operation on the same pointer (address).
3. The source code cannot run the free operation to point to a global variable or a local variable pointer operation, but free-to-air applications can be NULL pointer.
4. After applying free operation for a pointer, its value will not change, but it points to an invalid memory area, then this pointer is called the “dangling pointer”. How to avoid dangling pointers: When you define a pointer variable, the pointer should be initialized properly, and after using free or delete to release memory, the pointer should be set to NULL.
5. When adopting malloc and free to manage memory, the smaller variable should not be placed into the dynamic memory, and we try to avoid frequent dynamic memory allocation and release. If a block of dynamic memory is no timely released, and the pointer will point elsewhere, it will cause a “memory leak”.
WINCE GRAPHICX DEVICE INTERFACE(GDI) RESOURCE LEAKS.
Using EVC program to achieve the drawing on the WINCE, we will strictly comply with the following drawing steps:
Step 1: Use Create Compatible DC function to create a memory device context variable dc;
Step 2: Use Create Compatible Bitmap function to create a memory bitmap variable bitmap;
Step 3: Use Select Object function to create an association of dc and bitmap; Step 4: Painting;
Step 5: Use the BitBlt function to transfers pixels to an object dc; Step 6: Select Object function disassociates bitmap from dc; Step 7: The destruction of the memory variable bitmap; Step 8: The destruction of the memory variable dc.
1. When using EVC programming process, we try to use CWnd :: GetDC function and CWnd :: Release DC function instead of the Get DC method and the Release DC method. When you run code that calls the CWnd::GetDC followed by the CWnd::Release DC, a memory leak of 4 bytes occurs[7]. To avoid this problem, do not use the CWnd class versions of the Get DC method and the Release DC method, and use the Get DC function and the Release DC function. For example:
CDC *pDC; RECT rect;
GetClientRect (&rect); for (int i = 0; i < 100; i++) {
pDC = GetDC (); ReleaseDC (pDC); }
If you run this code and then check the system memory before and after you run the code, you notice that the system memory leaks four bytes per iteration. If the code above statement: pDC = GetDC () into hDC = :: GetDC (m_hWnd), ReleaseDC (pDC) changed :: ReleaseDC (m_hWnd, hDC), run the program, the memory leak does not occur.
2. If we are too frequent to use CreateCompatibleDC function, where the specified variable is created and these variables are defined as a global unity of member variables. We need to release them in the destructor, otherwise a memory leak will be produced.
3. When all kinds of GDI resource objects is called for drawing process, these processes must be in accordance with fixed order release or delete, otherwise it will cause a memory leak. Several attentions to the use of GDI resources:
a. Using the Create function to generate GDI objects, you must use Deleteobject release function. Using CreateCompatibleDC function to generate a variable DC, you must use the DeleteDc function to release the DC, and using getDC function derived DC, you must use ReleaseDc function to release it.
b. Using the object Create function to generate an object and using the delete function to release the memory, we need to follow the principle of first generation after being released. Create function generates the sequential variables: create1, create2, ..., createn, and the released order of the variables: deteten, ..., delete2, delete1.
c. The order of releasing Bitmap class variables and CPen class variables can not be changed, firstly CPen is released, then CBitmap is released.
4. After using Select Object function to select objects in the program, you must promptly return to the previous object, otherwise it will lead to memory leaks. For example:
HDC hMemDC;
pOldmap =(HBITMAP)Select Object(hMemDC,hMemBitmap); ...
SelectObject(hMemDC,pOldmap); ...
If the above code does not contain the Select Object(hMemDC, pOldmap), it will cause severe memory leaks. In addition, we also pay attention to the order of Delete Object (hMemBitmap) and Delete DC (hMemDC), DeleteDC must run after Delete Object , otherwise it will cause Delete DC call fails and can cause a memory leak.
The contents above are summed up several major conditions of the memory leak process of WINCE system and EVC programming. Considering the running WINCE embedded systems actually, this article discusses memory leaks and embedded system hazards, and pointed out the existence of this source code source issues during EVC programming. This paper presents the causes and prevention of some memory leaks, which can effectively prevent the occurrence and location of the system memory leaks, and this information can be further used for memory garbage recycling, while ensuring the normal operation of the system.
REFERENCES
1. Wangbing, Licehnbin, Embedded Visual C++ Embedded Programming. Waterpub.
2. Douglas Boling, Programming Windows Embedded CE 6.0 Developer Reference, China
Machine Press.
3. http://geekswithblogs.net/BruceEitman/archive/2008/12/22/platform-builder-config.bib.aspx.
4. Samuel Phung, Professional Microsoft Windows Embedded CE 6.0 Wrox Programmer to
Programmer, Wiley Publishing, Inc.
5. http://blog.csdn.net/hyalbert8084/archive/2007/09/19/1790791.aspx.
6. https://msdn.microsoft.com/en-us/library/ms859665.aspx.