Compact Framework bug?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm think I might have found a bug in the Compact Framework (I'm using v1.0 sp2). I've written a method that:

- creates a DOM object
- Imports and appends some nodes contained in a number of XML files
- writes the DOM object out to a new XML file

When I run this on a Pocket PC - or even on an emulator - the method eats up fair amount of memory, but does not release it at the end, even if I explitly collect all garbage. And it seems to cause knock-on effects - the MSDN PocketGuid code starts to throw an exception.

I've run the exact same code on a Windows PC, and the memory is released after the method exits. I used a profiler (couldn't find one for the CF) to check this - lots of strings and XmlText objects, all being released when they should be.

So, my questions are these:

- can anyone from Microsoft confirm this is a CF bug? No-one else seems to have reported it, so I'm a bit cautious about this
- has anyone else found this?
- if so, have they found a better workaround than I have? I just make the application quit, warning the user to restart it. Not very graceful...

thanks

ireo
 
No, no such problems have been reported.

First of all, why do you think memory used by DOM is not released?
Did you try to compare memory amount before creating the DOM and after
<forced> collection?
What are the numbers? Are you sure you keep no references to the DOM?

Also, GC on desktop and CF are very different and could collect at
completely different moments.
GC does not have to run on method exit, but memory has to be released if
you force collection, though.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
Thread-Topic: Compact Framework bug?
thread-index: AcRKPF7eBt99VY/zQmSSZ5W80AQGPg==
X-WN-Post: microsoft.public.dotnet.framework.compactframework
From: "=?Utf-8?B?aXJlbw==?=" <[email protected]>
Subject: Compact Framework bug?
Date: Fri, 4 Jun 2004 07:01:02 -0700
Lines: 21
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
Path: cpmsftngxa10.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.compactframework:54555
NNTP-Posting-Host: tk2msftcmty1.phx.gbl 10.40.1.180
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

I'm think I might have found a bug in the Compact Framework (I'm using
Click to expand...
v1.0 sp2). I've written a method that:

- creates a DOM object
- Imports and appends some nodes contained in a number of XML files
- writes the DOM object out to a new XML file

When I run this on a Pocket PC - or even on an emulator - the method eats
up fair amount of memory, but does not release it at the end, even if I
explitly collect all garbage. And it seems to cause knock-on effects - the
MSDN PocketGuid code starts to throw an exception.

I've run the exact same code on a Windows PC, and the memory is released
after the method exits. I used a profiler (couldn't find one for the CF)
to check this - lots of strings and XmlText objects, all being released
when they should be.

So, my questions are these:

- can anyone from Microsoft confirm this is a CF bug? No-one else seems to
have reported it, so I'm a bit cautious about this
- has anyone else found this?
- if so, have they found a better workaround than I have? I just make the
application quit, warning the user to restart it. Not very graceful...

thanks

ireo
 
Hi Ilya – thanks for your repl

I’ve been going by the figures on the Settings > System > Memory page. The ‘Program – In Use’ figure rises steadily the first time the method is run, then stays fairly static on subsequent runs

I’ve managed to boil the application down to one flat method; I’m thinking this would rule out the possibility of any DOM references hanging about. Also, I call GC.Collect() afterwards.

The numbers

(Conditions: run in debug mode on the PPC2003 SDK emulator, but I know the same problem occurs on the target device - an iPAQ

Total Main Memory: 43.68 M
Storage memory – stays static, apart from the one file being written to disk (as expected

Program Main Memory: 22.75 MB allocate

Before 1st run of method:

In use: 8.09 M
Free: 14.66 M

After 1st run

In use: 13.0
Free: 9.7

After 2nd run

In use: 13.0
Free: 9.7

After 3rd run

In use: 13.0
Free: 9.7

After 4th run

In use: 13.1
Free: 9.5

After 5th run

In use: 13.1
Free: 9.5

I’ve also run the same mini-application on my PC (it works!) and used a profiler. That shows total memory used going up to 9.15MB during the method (every time), but falling to around 239k afterwards (every time)

I’d be grateful for any further assistance/advice you could offer - be glad to send you the code, if it helps

thank

ire
 
If it stays static on subsequent calls, there's no memory leak. Memory
might be allocated on a first call to load and JIT huge DOM code.

I would suggest adding a call to GC.Colect()/GC.GetTotalMemory() on method
entry and exit and see if there's a difference.

You could also allow GC statistics. Please see this for more details:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=XI0KJFU2CHA.2560%
40cpmsftngxa06&rnum=2&prev=/groups%3Fq%3DGC%2Bstat%2Bgroup:microsoft.public.
dotnet.framework.compactframework%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dm
icrosoft.public.dotnet.framework.compactframework%26selm%3DXI0KJFU2CHA.2560%
2540cpmsftngxa06%26rnum%3D2

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=sTPiISbbDHA.1536%
40cpmsftngxa06.phx.gbl&rnum=1&prev=/groups%3Fq%3DGC%2Bstat%2Bgroup:microsoft
.public.dotnet.framework.compactframework%26hl%3Den%26lr%3D%26ie%3DUTF-8%26g
roup%3Dmicrosoft.public.dotnet.framework.compactframework%26selm%3DsTPiISbbD
HA.1536%2540cpmsftngxa06.phx.gbl%26rnum%3D1

You sure can post a repro code so I can try it here.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
Thread-Topic: Compact Framework bug?
thread-index: AcRNV0GKmUuJN76/RX6NZ9UtieEQhA==
X-WN-Post: microsoft.public.dotnet.framework.compactframework
From: "=?Utf-8?B?aXJlbw==?=" <[email protected]>
References: <[email protected]>
Click to expand...
Subject: RE: Compact Framework bug?
Date: Tue, 8 Jun 2004 05:51:03 -0700
Lines: 54
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.public.dotnet.framework.compactframework
Path: cpmsftngxa10.phx.gbl
Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.compactframework:54713
NNTP-Posting-Host: tk2msftcmty1.phx.gbl 10.40.1.180
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

Hi Ilya – thanks for your reply
Click to expand...

I’ve been going by the figures on the Settings > System > Memory page.
The ‘Program – In Use’ figure rises steadily the first time the
method is run, then stays fairly static on subsequent runs.

I’ve managed to boil the application down to one flat method; I’m
thinking this would rule out the possibility of any DOM references hanging
about. Also, I call GC.Collect() afterwards.

The numbers:

(Conditions: run in debug mode on the PPC2003 SDK emulator, but I know the
same problem occurs on the target device - an iPAQ)

Total Main Memory: 43.68 MB
Storage memory – stays static, apart from the one file being written to
disk (as expected)

Program Main Memory: 22.75 MB allocated

Before 1st run of method:

In use: 8.09 MB
Free: 14.66 MB

After 1st run:

In use: 13.01
Free: 9.74

After 2nd run:

In use: 13.05
Free: 9.70

After 3rd run:

In use: 13.05
Free: 9.70

After 4th run:

In use: 13.16
Free: 9.59

After 5th run:

In use: 13.16
Free: 9.59


I’ve also run the same mini-application on my PC (it works!) and used a
profiler. That shows total memory used going up to 9.15MB during the method
(every time), but falling to around 239k afterwards (every time).

I’d be grateful for any further assistance/advice you could offer - be
glad to send you the code, if it helps.

thanks

ireo
 
Back
Top