X Scale freezes

[masCh]

Hola. My first topic here so forgive me if I sound enthusiatic =P

I've recently developed a couple of apps, one using the pocketfrog libraries by Thierry and one using EVC's own MFCs.

My problem is both games can run fine on my ipaq 3870 and someone's 36xx series but I've had a couple of reports that it causes Toshiba (X-scale) and the 3970 (also X-scale) to freeze on some occasions.

I have no idea how that could happen because the one using MFC does not use external classes at all and it can still freeze? Well yes it could be my coding that really sux0rz but I cannot find a clue as to why.

My only assumption is that my file reading/writing routine could cause their systems to freeze. I use a text file as storage (check high scores for the game and ctreectrl items for the app). I access the text file quite often, maybe once in every 2 secs. The way I do it right now is that I read the whole file, store it into an array, edit some entries and write a new file with the same name to save the array. I believe there's a better way to do this but I have no idea how.

Does anyone here think that could be the problem? If so then how come I can do so many things on my strongARM and not encounter the same problem?

If file access is the problem, then is there a better solution? I dont know, if there is, please teach me.

Thanks in advance.

masCh

[refractor]

[masCh]

[refractor]

[Sm!rk]

[masCh]

[Dan East]

[Sm!rk]

[masCh]

Hrmm, I've changed my code so that it doesnt save states every 2 secs. Now if the user presses something then I save to file.

The problem code I think is with my CTreeCtrl object. I cannot detect if the user hit the checkbox or no. I dont know how to use HitTest. So to save myself from headaches I'd just save the file every few secs. If I can detect if the user hits the checkbox then I can get rid of that part of the code. The checkbox was made using the dialog wizard with the checkbox option turned on.

The problem with my game is also during file access. Both in my game and this CTreeCtrl app I used arrays to store file data. So my X-Scale freezing problem could be either the array or the file opening/writing/reading.

My biggest question is probably why does it only happen with X-Scale devices? I dont have an X-Scale device and I could not test my codes extensively on it.

[Dan East]

More than likely you have a bug in your code that only manifests on that hardware. I've seen that type of thing happen many, many times. Typically it is from writing past the end of an array.

Dan East

[Deje]

[masCh]

Hrmm I have no idea what Dan said =) If you write past an array wont that give you an error? Like out of bounds or something. I thought I've seen that happen. I'm assuming you mean int array[30] and I try to write array[30]=20; That would give it an error wont it?

Deje, how do you use assert and what does it do? Will it terminate the program if it finds a buggy array or something?

Answer to your question, yeah afraid of resets and crashes and all data will be lost. I only use one data file per app so far. But I dont think its because I access files often.. because in my other software (the game) I only check/write high scores and that causes problems in some 39xx series. I only do that once.

What is a memory mapped file? Dont need a major description, just a small one so I can decide if I want to really take a look at it and then I'll search for it on the web.

I'm starting to think that its because I save file states in the array and the problem could be somewhere there.

I dont have my code with me here at work or I could post what I'm doing.

By the way, thanks for all the help so far guys, I just realized there are so many things I've overlooked

[fzammetti]

No, you won't get an error if you write past the bounds of an array. Unfortunately in that respect, this isn't Java!

I know this from recent experience... My current project I had an array that gets cleared at the beginning of various screens in the game. Well, I was off by 1 when clearing the array, and what would happen is that if I compiled the program as a debug build, no problem manifested itself. However, when I switched to a release build, a completely unrelated screen was giving me problems.

I know that release builds by default turn off array bounds checking, and my assumption is that those checks, which would be present in a debug build usually, just stop the overwrite from happening, but still give no error. I could be wrong about that.

It was either that, or it must have been laying the allocated array memory out differently in release vs. debug and the off-by-one loop was only causing a problem when it was layed out a certain way, i.e., how it was in the release build (spent the better part of a day walking through code line-by-line banging my head against the desk before I figured that one out).

So, ignoring my pointless and somewhat off-topic babbling...

Could it be a debug vs. release build issue?

And in either case, you won't get any error if you overwrite bounds arrays. C just isn't that nice!

Also, your thought that if might not be the file access but the array maniulations should be easy to test: simply comment out the code that writes to a file, but leave all the array stuff intact. If it's the array code, you should still see your freezes.

A memory-mapped file by the way is basically just a file that you treat as a chunk of memory. Not sure that would really benefit you much here, but that's a very simplistic explanation anyway.

[refractor]

One thing to bear in mind is that you shouldn't let the software read+write to a flash-media frequently (because it'll destroy the media).

[masCh]