Skip to main content

Recursion problems on the BlackBerry Pearl

12 replies [Last post]
Anonymous

Hi,

Has anyone come up against problems with recursive methods when running
on a BlackBerry Pearl?

We've found that two recursive methods in a MIDlet fail with
inexplicable NullPointerExceptions on that device only. It makes no
sense because there is a check that the object in question isn't null.

We've even stopped the method actually being called multiple times and
have copied the code inside itself, yet the exception still occurs in
the same place.

And it was all looking so promising... :-(

Cheers,
Kirwan

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Stefan Haustein

Hi Kiwan,

I think for blackberry we had to switch off using the same name with
upper and lower case letters in the obfuscator, perhaps that may help....?

Best regards,
Stefan Haustein

Kirwan Lyster wrote:
> Thanks for all the suggestions which came through. We seem to have got
> to the root of the trouble, and it doesn't appear to have been anything
> wrong with the code.
>
> Rather than creating a COD file, we were simply sending a JAD and JAR as
> normal. I now realise that when the phone is sent a JAR, it does some
> internal work to convert it and that was going wrong when it tried to
> work with obfuscated code.
>
> With an obfuscated JAR, the problem occurs, but not with an unobfuscated
> version or with a COD file.
>
> Our COD file is currently coming to about 170KB. Should that be OK? I
> saw Eric say somewhere that 128KB is the maximum. If so, are there any
> handy tips for reducing the size? Our obfuscated JAR is about 120KB.
>
> Cheers,
> Kirwan
>
>
> Eric Giguere wrote:
>> Robin Chaddock wrote:
>>> It amazes me how VM implementors can take a well written very clear and
>>> concise document such as the JVM spec.
>>> Then mis-interpret it in such a fundamental way as to create a VM
>>> implementation that breaks in god-aweful ways.
>>
>> The BlackBerry VM is not actually a Java VM. It's a Java-like VM. Java
>> bytecodes must be converted into their own bytecode format before the
>> app can run. That said, for the most part it looks and behaves like a
>> Java VM. I certainly haven't run into any recursion issues. We do some
>> pretty sophisticated stuff in the AvantGo for BlackBerry client and it
>> works quite well. The Pearl and the 8800 are very nice devices to use.If
>> you're at the Wireless Enterprise Symposium next week (the BlackBerry
>> conference) then be sure to visit the Sybase booth and tell 'em Eric
>> sent you there.
>>
>> Eric
>> http://blackberry.synclastic.com
>>
>> ===========================================================================
>>
>>
>> To unsubscribe, send email to listserv@java.sun.com and include in the
>> body
>> of the message "signoff KVM-INTEREST". For general help, send email to
>> listserv@java.sun.com and include in the body of the message "help".
>>
>>
>
> ===========================================================================
>
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Eric Giguere

Kirwan Lyster wrote:
> Rather than creating a COD file, we were simply sending a JAD and JAR as
> normal. I now realise that when the phone is sent a JAR, it does some
> internal work to convert it and that was going wrong when it tried to
> work with obfuscated code.

The conversion actually occurs on the proxy server (BES or BIS) that the
device is using to fetch the file.

> With an obfuscated JAR, the problem occurs, but not with an unobfuscated
> version or with a COD file.

Sounds like a bug in the converter, actually.

> Our COD file is currently coming to about 170KB. Should that be OK? I
> saw Eric say somewhere that 128KB is the maximum. If so, are there any
> handy tips for reducing the size? Our obfuscated JAR is about 120KB.

My experience is that any COD file over 64K in size will cause problems
on certain BlackBerry models for OTA download. The newer models will
support 128K files where the file has no more than 64K each of code and
data, but for maximum compatibility you need to split your project into
multiple COD files if OTA download is required.

BTW, we just released the 1.0 version of AvantGo for the BlackBerry
yesterday, see the press release here:

http://www.rim.com/news/partner/2007/pr-08_05_2007-26.shtml

Here's what the JAD file for it looks like:

MIDlet-Version: 1.0.3
MIDlet-Name: AvantGo
MIDlet-Description: AvantGo
MIDlet-Vendor: iAnywhere Solutions, http://www.ianywhere.com
RIM-COD-URL-1: AvantGo_Library_Utils.cod
RIM-COD-Size-1: 34712
RIM-COD-URL-2: AvantGo_Browser_Resources_4.cod
RIM-COD-Size-2: 29868
RIM-COD-URL-3: AvantGo_Browser_Resources_3.cod
RIM-COD-Size-3: 16332
RIM-COD-URL-4: AvantGo_Browser_Resources_2.cod
RIM-COD-Size-4: 43112
RIM-COD-URL-5: AvantGo_Browser_Resources.cod
RIM-COD-Size-5: 43556
RIM-COD-URL-6: AvantGo_Library_Data.cod
RIM-COD-Size-6: 57224
RIM-COD-URL-8: AvantGo_Library_Sync.cod
RIM-COD-Size-8: 51324
RIM-COD-URL-9: AvantGo_Browser_Controls.cod
RIM-COD-Size-9: 40940
RIM-COD-URL-10: AvantGo_Browser_Content.cod
RIM-COD-Size-10: 24048
RIM-COD-URL-11: AvantGo_Browser_UI.cod
RIM-COD-Size-11: 38280
RIM-COD-URL-12: AvantGo_System.cod
RIM-COD-Size-12: 22564
RIM-COD-URL-13: AvantGo.cod
RIM-COD-Size-13: 65364

As you can I see, I've kept all the modules (this is after signing)
below 65535 bytes, just barely in some cases.

Be aware also that the rapc compiler (the one that creates cod files)
sometimes creates a cod file that is a ZIP file containing two or more
COD files. Those files cannot be downloaded OTA, you will get a 907
(Invalid ZIP) error trying to download it.

Eric
http://blackberry.synclastic.com

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Kirwan Lyster

Thanks Eric. That's all really useful to know.

Eric Giguere wrote:
> Kirwan Lyster wrote:
>> Rather than creating a COD file, we were simply sending a JAD and JAR as
>> normal. I now realise that when the phone is sent a JAR, it does some
>> internal work to convert it and that was going wrong when it tried to
>> work with obfuscated code.
>
> The conversion actually occurs on the proxy server (BES or BIS) that the
> device is using to fetch the file.
>
>> With an obfuscated JAR, the problem occurs, but not with an unobfuscated
>> version or with a COD file.
>
> Sounds like a bug in the converter, actually.
>
>> Our COD file is currently coming to about 170KB. Should that be OK? I
>> saw Eric say somewhere that 128KB is the maximum. If so, are there any
>> handy tips for reducing the size? Our obfuscated JAR is about 120KB.
>
> My experience is that any COD file over 64K in size will cause problems
> on certain BlackBerry models for OTA download. The newer models will
> support 128K files where the file has no more than 64K each of code and
> data, but for maximum compatibility you need to split your project into
> multiple COD files if OTA download is required.
>
> BTW, we just released the 1.0 version of AvantGo for the BlackBerry
> yesterday, see the press release here:
>
> http://www.rim.com/news/partner/2007/pr-08_05_2007-26.shtml
>
> Here's what the JAD file for it looks like:
>
> MIDlet-Version: 1.0.3
> MIDlet-Name: AvantGo
> MIDlet-Description: AvantGo
> MIDlet-Vendor: iAnywhere Solutions, http://www.ianywhere.com
> RIM-COD-URL-1: AvantGo_Library_Utils.cod
> RIM-COD-Size-1: 34712
> RIM-COD-URL-2: AvantGo_Browser_Resources_4.cod
> RIM-COD-Size-2: 29868
> RIM-COD-URL-3: AvantGo_Browser_Resources_3.cod
> RIM-COD-Size-3: 16332
> RIM-COD-URL-4: AvantGo_Browser_Resources_2.cod
> RIM-COD-Size-4: 43112
> RIM-COD-URL-5: AvantGo_Browser_Resources.cod
> RIM-COD-Size-5: 43556
> RIM-COD-URL-6: AvantGo_Library_Data.cod
> RIM-COD-Size-6: 57224
> RIM-COD-URL-8: AvantGo_Library_Sync.cod
> RIM-COD-Size-8: 51324
> RIM-COD-URL-9: AvantGo_Browser_Controls.cod
> RIM-COD-Size-9: 40940
> RIM-COD-URL-10: AvantGo_Browser_Content.cod
> RIM-COD-Size-10: 24048
> RIM-COD-URL-11: AvantGo_Browser_UI.cod
> RIM-COD-Size-11: 38280
> RIM-COD-URL-12: AvantGo_System.cod
> RIM-COD-Size-12: 22564
> RIM-COD-URL-13: AvantGo.cod
> RIM-COD-Size-13: 65364
>
> As you can I see, I've kept all the modules (this is after signing)
> below 65535 bytes, just barely in some cases.
>
> Be aware also that the rapc compiler (the one that creates cod files)
> sometimes creates a cod file that is a ZIP file containing two or more
> COD files. Those files cannot be downloaded OTA, you will get a 907
> (Invalid ZIP) error trying to download it.
>
> Eric
> http://blackberry.synclastic.com
>
> ===========================================================================
>
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>

--
Kirwan Lyster
Head of Mobile Development » Reporo

e » kirwan.lyster@reporo.com
t » +44 (0)20 7928 8128

Reporo
Europoint Centre
5-11 Lavington Street
London
SE1 0NZ
United Kingdom

t » +44 (0)20 7928 8128

w » www.reporo.com

------------------------------------------------------------------------
Disclaimer »
The information contained in this e-mail is confidential and is intended
for the recipient only.
If you have received it in error, please notify us immediately by reply
e-mail and then delete it from your system.
Please do not copy it or use it for any other purposes, or disclose the
content of the e-mail to any other person or store or copy the
information in any medium.
The views contained in this e-mail are those of the author and not
necessarily those of Reporo.
------------------------------------------------------------------------

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Eric Giguere

Robin Chaddock wrote:
> It amazes me how VM implementors can take a well written very clear and
> concise document such as the JVM spec.
> Then mis-interpret it in such a fundamental way as to create a VM
> implementation that breaks in god-aweful ways.

The BlackBerry VM is not actually a Java VM. It's a Java-like VM. Java
bytecodes must be converted into their own bytecode format before the
app can run. That said, for the most part it looks and behaves like a
Java VM. I certainly haven't run into any recursion issues. We do some
pretty sophisticated stuff in the AvantGo for BlackBerry client and it
works quite well. The Pearl and the 8800 are very nice devices to use.If
you're at the Wireless Enterprise Symposium next week (the BlackBerry
conference) then be sure to visit the Sybase booth and tell 'em Eric
sent you there.

Eric
http://blackberry.synclastic.com

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Kirwan Lyster

Thanks for all the suggestions which came through. We seem to have got
to the root of the trouble, and it doesn't appear to have been anything
wrong with the code.

Rather than creating a COD file, we were simply sending a JAD and JAR as
normal. I now realise that when the phone is sent a JAR, it does some
internal work to convert it and that was going wrong when it tried to
work with obfuscated code.

With an obfuscated JAR, the problem occurs, but not with an unobfuscated
version or with a COD file.

Our COD file is currently coming to about 170KB. Should that be OK? I
saw Eric say somewhere that 128KB is the maximum. If so, are there any
handy tips for reducing the size? Our obfuscated JAR is about 120KB.

Cheers,
Kirwan

Eric Giguere wrote:
> Robin Chaddock wrote:
>> It amazes me how VM implementors can take a well written very clear and
>> concise document such as the JVM spec.
>> Then mis-interpret it in such a fundamental way as to create a VM
>> implementation that breaks in god-aweful ways.
>
> The BlackBerry VM is not actually a Java VM. It's a Java-like VM. Java
> bytecodes must be converted into their own bytecode format before the
> app can run. That said, for the most part it looks and behaves like a
> Java VM. I certainly haven't run into any recursion issues. We do some
> pretty sophisticated stuff in the AvantGo for BlackBerry client and it
> works quite well. The Pearl and the 8800 are very nice devices to use.If
> you're at the Wireless Enterprise Symposium next week (the BlackBerry
> conference) then be sure to visit the Sybase booth and tell 'em Eric
> sent you there.
>
> Eric
> http://blackberry.synclastic.com
>
> ===========================================================================
>
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Federico Paparoni

The limit size for the COD is 128K (if you want to install the application
OTA) but you can easily create different COD files.
>From the JDE 4.1, the IDE automatically creates a JAD with different CODs
but sometimes there is problem when installing the applications using the
WAP browser.

Read the following link for further informations

http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/...

Cheers

--
Federico Paparoni

Website http://www.javastaff.com
Blog http://doc.javastaff.com

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Dane ©oba

Hi,

What is probably happening is that the recursive methods use up too much
heap and the system does an emergency garbage collection,
which will remove least used objects on heap, even if there is still a
reference on them.

What you can do to solve this problem:

1. First of all, you shouldn't be using recursion at all. Recursion uses a
lot of heap for every recursive call, as it has to store every local
variable on the heap. This can quite quickly overrun the heap so the system
has to do an emergency garbage collection.

Every recursive method can be implemented as an iterative method. If the
method has tail recursion (the recursive calls only happen at the end of
the method or there is no code after the recursive call) then this can
trivially be changed into an iteration (while loop).

Otherwise, you have to create your own stack (using Vector or array) and
push the local variables that will be changed in the recursive call to your
stack, then pop them when the recursive call is ended.

If you post some of your code (esp. the method parameters and location of
the recursive calls inside the recursive method) i could suggest a more
specific solution.

2. Implement the LowMemoryListener interface and handle low memory events.
The system will call all registered low memory listeners before an
emergency garbage collection so you can manually delete objects that can
safely be deleted (cache etc.). You can find more details in the Blacberry
development guide.

Best regards,
Dane ©oba

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Robin Chaddock

Dane ©oba wrote:
> Hi,
>
> What is probably happening is that the recursive methods use up too much
> heap and the system does an emergency garbage collection,
> which will remove least used objects on heap, even if there is still a
> reference on them.
>
Wow! Realy?!

It amazes me how VM implementors can take a well written very clear and concise document such as the JVM spec.
Then mis-interpret it in such a fundamental way as to create a VM implementation that breaks in god-aweful ways.

"An object enters an /unreachable/ state when no more strong references to
it exist*. When an object is unreachable, it is a /candidate/ for
collection

*(that chain from a garbage collection root)"

________________________________________________________________________
E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which I-play, a trading name of Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

(C) 2005. I-play is a trademark and trading name of Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Java

Robin Chaddock wrote:
> Dane ©oba wrote:
>
>> Hi,
>>
>> What is probably happening is that the recursive methods use up too much
>> heap and the system does an emergency garbage collection,
>> which will remove least used objects on heap, even if there is still a
>> reference on them.
>>
> Wow! Realy?!
>
> It amazes me how VM implementors can take a well written very clear and
> concise document such as the JVM spec.
> Then mis-interpret it in such a fundamental way as to create a VM
> implementation that breaks in god-aweful ways.
>
> "An object enters an /unreachable/ state when no more strong references to
> it exist*. When an object is unreachable, it is a /candidate/ for
> collection
>
> *(that chain from a garbage collection root)"

Indeed, this would be extremely surprising.

Dane, can you point out the BlackBerry spec that says that referenced
objects may still be cleared by the GC? Or maybe provide a test case?
The specs I've found only talk about *un-referenced" objects.

David

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Dane Å oba

Hi,

What is probably happening is that the recursive methods use up too much
heap and the system does an emergency garbage collection,
which will remove least used objects on heap, even if there is still a
reference on them.

What you can do to solve this problem:

1. First of all, you shouldn't be using recursion at all. Recursion uses a
lot of heap for every recursive call, as it has to store every local
variable on the heap. This can quite quickly overrun the heap so the
system has to do an emergency garbage collection.

Every recursive method can be implemented as an iterative method. If the
method has tail recursion (the recursive calls only happen at the end of
the method or there is no code after the recursive call) then this can
trivially be changed into an iteration (while loop).

Otherwise, you have to create your own stack (using Vector or array) and
push the local variables that will be changed in the recursive call to
your stack, then pop them when the recursive call is ended.

If you post some of your code (esp. the method parameters and location of
the recursive calls inside the recursive method) i could suggest a more
specific solution.

2. Implement the LowMemoryListener interface and handle low memory events.
The system will call all registered low memory listeners before an
emergency garbage collection so you can manually delete objects that can
safely be deleted (cache etc.). You can find more details in the Blacberry
development guide.

Best regards,
Dane Å oba

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Michael Flad

Do you use repaint/serviceRepaints() called from within your main
update thread?

I only have experience on some other BlackBerry handsets but on
those serviceRepaints didn't block. So your paint may be called at
a later time (which may be during a state change of your app while
you're loading/creating some resource used for painting).

Regards,
Michael

> -----Ursprüngliche Nachricht-----
> Von: A mailing list for KVM discussion
> [mailto:KVM-INTEREST@JAVA.SUN.COM] Im Auftrag von Kirwan Lyster
> Gesendet: Freitag, 4. Mai 2007 16:40
> An: KVM-INTEREST@JAVA.SUN.COM
> Betreff: Recursion problems on the BlackBerry Pearl
>
> Hi,
>
> Has anyone come up against problems with recursive methods
> when running on a BlackBerry Pearl?
>
> We've found that two recursive methods in a MIDlet fail with
> inexplicable NullPointerExceptions on that device only. It
> makes no sense because there is a check that the object in
> question isn't null.
>
> We've even stopped the method actually being called multiple
> times and have copied the code inside itself, yet the
> exception still occurs in the same place.
>
> And it was all looking so promising... :-(
>
> Cheers,
> Kirwan
>
> ==============================================================
> =============
> To unsubscribe, send email to listserv@java.sun.com and
> include in the body of the message "signoff KVM-INTEREST".
> For general help, send email to listserv@java.sun.com and
> include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Kim Daniel Arthur

Hei,

Can you post the code in question? Do you have multiple Threads running?

Kim

On 4/5/07 15:40, "Kirwan Lyster" wrote:

> Hi,
>
> Has anyone come up against problems with recursive methods when running
> on a BlackBerry Pearl?
>
> We've found that two recursive methods in a MIDlet fail with
> inexplicable NullPointerExceptions on that device only. It makes no
> sense because there is a check that the object in question isn't null.
>
> We've even stopped the method actually being called multiple times and
> have copied the code inside itself, yet the exception still occurs in
> the same place.
>
> And it was all looking so promising... :-(
>
> Cheers,
> Kirwan
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".