All geek questions in one place

Avoiding a Serious Mistake in .NET CF 3.5 and CE 6 R3

When I run this sample program on a device with a debugger attached, a serious error occurs.

This is a stripped-down version of what is happening in our real application.

What I learned:

  • Debugger must be attached
  • The memory should be full somehow (I think this will force garbage collection)
  • Garbage (raster) objects must exist. Other objects may cause the same error.
  • The form should be shown (no difference if Application.Run () or ShowDialog is used)

Then, when the form is visible and the GC collects the bitmap images, a serious error occurs.

I am running WindowsCE 6 R3 with the .NET Compact Framework 3.5.

static class Program { static void Main() { // Fill up memory - Depends on device var memory = new int[100000 * 150]; // Settings the priority higher will raise the error earlier. // With Priority set to Normal the EXE won't get freed correct. // Without this line i have to reboot the CE after every test run... Thread.CurrentThread.Priority = ThreadPriority.Highest; // 80 is just random choosen. The error occurs also with 30 Bitmaps... for (int o = 1; o < 80; o++) { // Create a Bitmap and don't free it manually. The // The garbage collector will take care of it :) var bitmap = new Bitmap(100, 100); // When i dispose the Bitmap, everything works fine... //bitmap.Dispose(); } // Force a GC run System.Diagnostics.Debug.WriteLine(GC.GetTotalMemory(true)); // Then error occurs when the form is shown. System.Windows.Forms.Application.Run(new System.Windows.Forms.Form()); } }

I already found similar questions, but not anwser ...

What I have tried so far:

  • Clear all resources manually. I already looked for all the raster creations and deleted them or cached them. The error is still happening, it's not just bitmaps that are bad ...
+4
source share
2 answers

I have a theory, and this is what the system reverses. If the debugger is trying to get the contents of a variable that is larger than the size of the CE paging pool , I could imagine this in a dead end. The debugger stopped the system for reading data, but the system cannot provide content because it cannot change data. Using IOCTL_HAL_GET_POOL_PARAMETERS, you can determine whether the system will be replaced or not.

+1
source

It is difficult to point out the answer.

When you say a serious error occurs , I assume that you are seeing an OutOfMemoryException .

The Garbage Collector (GC) starts when the Framework allocates GC time or calls it.

If you create / use memory faster than the Framework can invoke the GC, you may run out of memory - especially in a CF application.

The MSDN link above states the following:

The .NET Framework garbage collector manages the allocation and release of memory for your application. Each time you use a new operator to create an object, the runtime allocates memory for the object from the managed heap. As long as the address space is available in the managed heap, the runtime continues to allocate space for new objects. However, the memory is not infinite. In the end, the garbage collector must complete the build to free some memory. The garbage collector optimization mechanism determines the best time to complete the collection based on the allocations made. When the garbage collector performs the collection, it checks the objects in the managed heap that are no longer used by the application and performs the necessary operations to restore their memory.

To get around this, you will need to free up resources as they are completed. If you need this data at some later point, you can save the resource to some medium (flash data, hard disk, etc.) for later search.

You can read more about this on Stephen Pratshner’s blog entitled .Net Compact Framework Garbage Collector Overview .

0
source

Source: https://habr.com/ru/post/1478960/

More articles:


All Articles