Hi Sebastian,
First, thanks for the very detailed report.
>I am getting a stack overflow when running gremlins on a japanese 3.5 rom.
>I increased the stack size by 800 bytes or so, but this pushed the gremlin
>only further back to a higher event number.
What's your app stack size set to?
>Also I measured that my app( before going into SysHandleEvent, see stack
>trace) only uses up about 600bytes of the stack.
>When I look at the stack trace it seems I am getting burried in system
>functions/apps( displaying the japanese input dialogs).
>
>Is this a known issue or do I have a bug in my code somehwere?
It's a known issue in 3.1 that became a bigger issue in 3.5. What's
happening is that you've got the following call sequence.
Your app
Find form
User dictionary panel (*1)
JEDict application (*2)
On-screen keyboard
All of these are auto-triggered, in that it's nothing your app is
doing explicitly, other than (correctly) giving the system a crack at
handling events.
On a Japanese device, two new items are automatically added to the
edit menu, if it looks like a standard system edit menu. These are
"Add word to FEP user dictionary" and "Look up work with the JEDict
application". The commands are similar to phone lookup, in that they
operate on the current field.
It turns out that the Find form has a standard system edit menu, thus
these two items get appended. Then Gremlins selects the "Add word to
FEP user dictionary" item, which triggers the sub-launch of the User
Dict panel. This also has a standard system edit menu, and Gremlins
happily selects the "Look up word with the JEDict application" menu
item, which triggers the sub-launch of the JEDict application. This
displays an edit field, so then the on-screen keyboard winds up
getting displayed.
On a 4.0J device running the Memo app, I see that 3634 bytes of stack
are getting chewed in a similar calling chain. The Memo app starts
out with a 4K stack, which then gets increased automatically by 1488
bytes (FEP + other OS overhead), so there's a total stack size of
5584 bytes. This gives it enough free space to handle the specific
calling sequence you described.
The above numbers imply that the minimum stack size when running on a
Japanese device is around 3K - the OS will bump this to about 4K,
which seems like it should be enough, though I didn't test what
happens when you receive a beam while converting text with the FEP in
the on-screen keyboard window. To be safe, I'd stick with a 4K stack
in the 'pref' resource.
-- Ken
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/