POCKET PC (WinCE) runtime lock up issue

[AndyH]

Hi Gernot.  Here's a small project simulating some of the things my game is doing (couldn't say if it makes much difference having all this in but it's a hard one to pin down and the more that goes on the quicker it seems to happen).

Run this on the PocketPC and it will eventually lock up making the Pocket PC dead until a reset.

I've put a timer in counting from when the program started, it has a flaw as I use  GETTIMERALL() so when subtracting the start time from the current time I display on screen it sometimes goes in to negative numbers.

On my Garmin PocketPC I have recorded the timer at -956.5, 1260.1 and 1264.8 (spookily close to the previous time) when it locks up and stops responding.  This PocketPC freezes up completely.  It has less available memory than the standard 64Mb because it has a proprietary Sat-Nav software that always loads which you can't kill off, but it only shaves off 10Mb at most.

I've now tested on an older Pocket PC (a Mio) and this started to misbehave at -524.7 but it slowed to a crawl initially rather than stopping alll together, taking anything from 2 seconds to 20 seconds to refresh the display but it did keep running (each refresh when it happened was one SHOWSCREEN).  This went on until -50.1 with no refresh until +55.0 when it finally stopped responding all together.  The Mio has more available memory - perhaps the reason.  It's also a slightly older version of Windows. (some times I recorded for each update were -524.7, -503.3, -483.8, -458.1, -446.7 ...)

I ran it a second time just now and it slowed down at -167.0 - I was able to quit out of it while it was still responding (although 2-20 seconds per SHOWSCREEN).

Hope you can track this down, as it's not practical to compile to PocketPC in this state.  Seems like a memory leak.  If so, could this affect every platform that is using the part of the code causing the issue?  I guess on Windows / Mac / Linux there's a lot more memory to soak up ... if it is this.  Maybe it's something else specific to the PocketPC?

Could you add a memory free command at all?  Maybe be useful to display the free available memory to see if that is the problem as it runs?

[AndyH]

More testing updates.  A bit of a pattern with when this code starts to have it's problems.

PPC 1 (the Garmin) - locked up at 1248.0  - very close to that 1260 and 1264 times reported above.

PPC 2 (the Mio) - Results for two more runs - I noticed it's time was over 1100 but both times glanced away and when looked back a few seconds later it had begun it's slow down at times of -60 and -85.  It's wrapped around but I bet it's close to that magic 1260 number!

I see there is an error log on the main memory storage in TEMP - nothing unusual showing in there (the Garmin has less info in it - stops after reporting the screen size and depth).  Let me know if I can get anything useful out of this for you.

Good hunting!

[Kitty Hello]

Does it happen when you touch the screen, or just by waiting?
Also, does it happen after a clean reset? Sometimes you stop a GLBasic program, but it's still in the background (strangely).

[AndyH]

Yes, I do a RESET (the inset button at the bottom or side that you have to click with the pen) then run.  I leave it to run, no mouse clicks (run off power or set the powersaving to not turn it off).  This program will run for approx 21 mins (the 1260 seconds above) and then lock up, or in the case of the Mio, slow down to 1 frame update every 2 to 20 seconds until it gives up.  On the Mio if I quit out while it is slowing down (I have a test for the fire button to quit) and then run right away, it will run at full speed for another 21 minutes.

[AndyH]

Run some more on the Garmin PPC this morning, lock ups at 943, 733, 1091 so a little more varied today but happens consistently every time.

[Kitty Hello]

can you post the "errorlog.txt" from your temp, when it's slowing down?

[AndyH]

Will do - I can do this only from the Mio as this is the only one that slows down.  I'm not sure if I'll be able to get access to the file without quiting out.  Is it ok to send the errorlog.txt after I quit out of the app once it slows down?

This is the contents of the file on the Garmin after it locked at 1212.5 seconds up and I have done a reset (doesn't have as many lines in it as the Mio one).

GlobalInit
Failed to load: Vibrate in m_hAYGSHELL
Failed to load: VibrateStop in m_hAYGSHELL
Failed to load: VibrateGetDeviceCaps in m_hAYGSHELL
Using GETRAWFRAMEBUFFER
Screen W,H,bpp
320
240
16
Ptich X,Y
2
480

I'll post the Mio one when I get home.

[Kitty Hello]

You're displaying a whole lot of numbers/times in your thingy.
So, how long does it take until it locks up?
I've tested with the emulator and it seemed to work constantly for about 3 minutes.

BTW: Pitch: 2,480 is the best - I've especially highly optimized the code for this display, since my n35 has that, too :p

[AndyH]

About 21 minutes (1260 seconds) on average with this project.  This is fairly consistent between two Pocket PC's.  Maybe if increase the number of things it does it might accelerate that... will give it a try.

Also my son has one from school, it does 640x480 resolution so I could test on that too.

[AndyH]

How's the progress on fixing this bug going?  I think the PocketPC needs a little love and attention when you have some time to do it.  There's a definite lock up going on (confirmed on all three PPC's I have tested on) which means I can't reliably release anything for the PPC/smartphone.  The PPC also needs that music support once this issue is sorted

[Kitty Hello]

Oh oh dear. Say, could you possibly make a large array (about 2/3 or your avaliable memory?)
like this:

Code (glbasic) Select Expand

sz  = num_megabytes * 1024*1024/4 // on PocketPC 4 bytes per "number"
DIM arr[sz]

WHILE TRUE
...print time and show you're alive
WENDAnd see, if the runtime until freeze gets shortened drastically? Then it's a memory leak problem. If not, it's uhm... oh dear.

[bigsofty]

Wumbo's Adventure on PPC freezes on level three, maybe related?

[AndyH]

I've tried this code:

Code (glbasic) Select Expand

//SETSCREEN 640,480,1
LIMITFPS 60


GLOBAL num_megabytes, n$
PRINT "Enter value of number of MBytes:",0,0
INPUT n$,0,10
SHOWSCREEN
IF n$=""
num_megabytes = 40
ELSE
num_megabytes = INTEGER( n$ )
ENDIF

sz  = num_megabytes * 1024*1024/4 // on PocketPC 4 bytes per "number"
DIM arr[sz]

BLACKSCREEN
DRAWRECT 1,1,30,30,RGB(255,0,0)
GRABSPRITE 0,0,0,32,32

BLACKSCREEN

GLOBAL cnt

WHILE TRUE
LOCAL t

FOR t=0 TO 200
DRAWSPRITE 0, RND(320), RND(240)
NEXT

PRINT "counter=" + cnt, 0,0
INC cnt,1

SHOWSCREEN
WENDI suspect it is to do with drawing commands as the more activity there (maybe loading or just drawsprite?) ... but that's just a hunch at the moment.  I'm going to have to get a proper hand held games console to play my GLB games on at some point aren't I :-P

OK, while I've been typing this, the above with 40 entered as the MB my PPC has froze with the counter at 8024.  I'll reset and run again then try some other values for the MB.  My PPC has a total of 64Mb btw.

[AndyH]

32099 on the counter after a clean reset.  If I allocate too much memory the program quits out but the START menu bar at the top of the PPC does not appear (I see a bit of the GLB program where the start bar should be) and I have to do a reset.

[Kitty Hello]

so, is it memory related?
I sent you an email through your website. Can you test with that new library? I might have found an issue there.