"Fatal error" on Tungsten E2

#1
Hi!

Sometimes I get a dialog box popping up saying "fatal error" on my Tungsten E2, with the only possible option being to reset. Since I bought it recently I've still not managed to collect enough data to make any empirical conclusions about the cause of the crash, but it seems that it happens pretty randomly (and not very often). Right now it happened while I was in PlecoDict. I also have SlovoEd En-En dictionary installed running in resident mode to look up english words I do not know from within PlecoDict. Except for that, I guess I don't have any other resident software. I guess the main suspect for me right now is the SlovoEd since it's running in resident mode, but it's really just speculation.

My real question is: What is needed for a program to be able to trigger a crash like this "randomly"? Does it have to be resident? Are programs which I open automatically "closed" again when I switch to some other program, provided that they don't have any resident mode functionality? Has anyone experienced crashes like this with PlecoDict + SlovoEd?

I'd be very happy if somebody could enlighten me about the ways of the Palm. :D

(NB: I'm not blaming PlecoDict for this crash!) :D
 
#2
I get random resets with my Treo 650. However, this is when I run a very badly behaving program in the background (I know which program it is and it shall remain nameless but it isn't PlecoDict).

My first suggestion to you might be to see if you can update the firmware on your E2. For the Treo 650, PalmOne came out with many firmware updates because the "original" Treo 650 had quite a few issues/problems and your random resets could be due to a "buggy" old firmware.
 

mikelove

皇帝
Staff member
#3
redpixel - Programs that you open are indeed closed again when you open some other program, so it's almost impossible for a program to cause a crash unless it's currently running or is running in some sort of resident mode like SlovoEd. So the two most likely sources of this recent crash are our software and SlovoEd. What were you doing in PlecoDict when it crashed - was the program just sitting idle or were you doing a search of some sort?
 
#4
Jim: Thanks, but unfortunately there doesn't seem to be any updated firmware for the E2. :(

Mike: I was "actively" using PlecoDict, looking up a word I think, but not doing any particularly fancy search. :) I'll see if I encounter it again and if I'm able to figure out how to make it reproducable. Still, I think it might very well be SlovoEd in this case because their resident feature seems a bit "weird".

[...]

Actually, as I was writing this I started experimenting a bit with searching and I must now say that this most likely is a PlecoDict bug... Now I tried searching with wildcards and as I was entering my search string Pleco froze for a few seconds and then gave me a fatal exception. After I pressed the reset button it gave me another fatal exception when booting. After resetting again it boots normally.

It doesn't seem to be reproducable though, entering the same search string (pinyin + wildcard) again only makes it freeze for a while while searching, not crash. Sorry :/

On a related note, I'm a bit confused as to how the searching with wildcards works. For example, searching for "cheng@" yields many results which are just 1 character. Is this the intended behaviour? I would expect to only see 2-character words in the "result" mode. Also, "cheng@shang@@" for example yields a few results, for example "cheng2qian1shang4wan4", but this seems a bit weird since it's only 4 characters. I would expect no results. "$cheng$" yields no results at all, which I would expect to show all the words containing any character pronounced "cheng". I guess the "correct" way of doing this is to search for just "$cheng" since you will get all the results ending with something too, but still, I would expect "$cheng$" to work too. :)

Also, is there any chance for a frequency sorted searching mechanism a la WenLin in 2.0? For example seeing all characters containing "cheng2" sorted in order of frequency. I realise that this might require a significant amount of extra space and maybe a lot of input data and processing time to generate the frequency tables but still, it would be cool, at least as an add-on. :)
 

mikelove

皇帝
Staff member
#5
Wildcard search is the single most memory-intensive thing you can do in PlecoDict (aside from starting a ridiculously huge flashcard session) so this sounds like some sort of out-of-memory error. That would also explain why it would happen semi-randomly. The way PlecoDict is supposed to handle a low-memory situation is by dumping everything in its memory cache and starting over with a clean slate, which is probably what's happening when you try the search again and it freezes for a few seconds (while it reloads data from your SD card). We haven't gotten many other reports of this sort of crash, so it might still have something to do with SlovoEd; perhaps the lack of memory is causing SlovoEd to crash, or perhaps SlovoEd is an exacerbating an already dangerously low-memory situation. But it could also be that there's some rare combination of events that causes PlecoDict to handle an out-of-memory error in a less-than-graceful way, so we'll take another look at this and see if we can come up with anything.

Regarding your wildcard issue, PlecoDict's indexing system doesn't yet support using wildcards at the end of a search query; one of the sacrifices we had to make in order to get it to perform reasonably well on a PDA. The main reasons we included wildcard search at all were to let people search for words by their second character and to search for words containing a particular character or pattern, so exact length matching didn't seem like as high of a priority. It's normally supposed to ignore trailing wildcards altogether, though, so I'm not sure why this $cheng$ search isn't working.

A frequency sorting mechanism like you describe is certainly doable, but it would indeed require a fair amount of work, and it's not something we've gotten a lot of requests for, so I don't know how likely it is to make it into 2.0.
 
#6
mikelove said:
Wildcard search is the single most memory-intensive thing you can do in PlecoDict (aside from starting a ridiculously huge flashcard session) so this sounds like some sort of out-of-memory error.
What would you qualify as being a ridiculously huge flashcard session?
 

mikelove

皇帝
Staff member
#7
Something on the order of 16,000 cards - each card in the queue takes up 4 bytes so this would be pushing up on the Palm OS' 64K memory segment limit. Though in most cases it won't actually let you start a session that big (or will give you a warning message saying it's cut off part of the session).
 
#8
mikelove said:
Something on the order of 16,000 cards - each card in the queue takes up 4 bytes so this would be pushing up on the Palm OS' 64K memory segment limit. Though in most cases it won't actually let you start a session that big (or will give you a warning message saying it's cut off part of the session).
LOL. I guess with my current 200 or so flashcards in a single flashcard session and increasing this by approximately 10 flashcards a week in my flashcard test sessions, I have nothing to worry about for a very long time. :D
 
#9
OK, thanks for clearing that up!

It makes sense that the primary use of wildcards would be to see words where only the 2nd or later character is known, since those are not directly "searchable" otherwise.

I'll keep investigating the bug and report back any news I find :) If it happens often I'll try to uninstall SlovoEd for a while too to see if that's what's causing it.
 

mikelove

皇帝
Staff member
#10
You're very welcome! And thanks for all the bug reports - these are exactly the sort of things that can be difficult for us to find on our own.
 
#11
I'm also having an issue with a TE2. If I turn off the Palm while using the flashcards the whole thing won't restart without doing a soft reset. A pretty big hassle.

Anybody else have that problem? Anybody have any ideas??

Thanks!
 
#12
Hi Jim!

I'm seeing the exact same problem, in fact I just wrote a new thread about it (before having seen your post here)! I think the only "solution" right now is to not turn it off/let it sleep while you're in the middle of a flashcard session :( Alternatively, I also found that removing the SD card will wake it up without having to do a soft reset. It's still a bit of a hassle though, since you have to restart your flashcard session (actually, after you remove your card it will wake up to the flashcard session but if you continue it will soon fail with a fatal error in PlecoDB.cpp since it doesn't have its dictionary anymore. This is of course assuming that some of your data files are on an SD card. If it's all in your main memory I don't know).
 
#13
fatal error on tungsten e2

i think am receiving the same fatal error.

it says "Fatal Alert: Form.c, Line:2978, Invalid index" and the only option is to reset.

it happens while using the handwriting input, as i am clicking on the recognized character. it has happened 5 times in a row today. each time i reset, but as soon as i use the handwriting input it happens again. i have noticed it only happens when the handwriting input is set to the bottom of the screen. if it is in fullscreen mode, or left or right, it is OK.

i have no other software running... in fact i ONLY use my PDA for plecodict, nothing else. i have used it successfully, i would say intensely (i am in china right now) daily for 4 weeks without any problem. any advice?
 

mikelove

皇帝
Staff member
#14
Are you using the latest version? (1.0.3) This was a known bug in an earlier version of PlecoDict, but we're pretty sure it's fixed now. You can check your current version by going to the About screen.
 

mikelove

皇帝
Staff member
#16
Hmm... did you enable Input Field Compatibility mode? (in the Characters section of Preferences?) If so, try turning it off - does that help? If not, try enabling it and then disabling it again.

Also, is "disable palette HWR after input" enabled in Preferences? If so, try turning that off - that's another thing we've gotten one or two bug reports about, though again it was supposed to be fixed in 1.0.3.
 
Top