10-01-2008 08:28 PM
Running Blackberry JDE version 184.108.40.206r, with 8330 simulator that reports Blackberry Device Simulator 220.127.116.11, and inside the simulator, Status-About reports v18.104.22.168 (Platform), and the real device is an 8330 Curve from Verizon that reports v22.214.171.124 (Platform 126.96.36.199).
So both the simulator and the device are a later revision than the JDE, which I understand is the requirement.
I've written a couple of apps that work in the simulator just fine, but when I sign the .cod file and install them on the real device, strange things happen, though they do seem to be repeatable, which is a good thing They can read the file system directories, and files, but some things just don't work. For example, one app can show the list of images on the disk, but can't show them on the device. Works fine on the simulator. Another reads files and determines the contents correctly, but when trying to push a field with some of the contents, it gets a blank field. So I attach the debugger to the device, and the debugger doesn't seem to follow as well as it does on the simulator.
For example, while the debugger is connected to the device, it doesn't show the contents of Strings like it does when connected to the simulator. Some times it shows null for a string but println statements have just printed that string and it's what I'd expect. Other times it shows an address for a string, but instead of the object type String and a value it shows "unknown(net_rim_cldc-8,61)" and other similar "unknown" object types.
It doesn't seem to be able to decode the exceptions either. I'll get "Uncaught Exception Thrown - <unknown>" and in the locals pane it reports it as "unknown(net_rim_cldc-1,3)". It's the exceptions that seem to be causing the problem in the app, but I can't figure out what the exception is.
The output window is also reporting numerous reports like: CMM: ClassicLit(1478) no sig from 0x33Enterprise UNIX Services -- Jumpstart Configurator
So have I got some mismatch in versions, or something else going on here? It's frustrating me. Has anyone gotten through this before and have some words of wisdom for me?
10-01-2008 08:37 PM
Here is some advice for debugging on the device:
1. Build and sign the application, transmit to the device, and debug. Make sure that the build on the device is identical to the build on the JDE - this will give you the best debugging results (although still not great). I get my best results when the build and the debug happen without restarting the JDE or touching the source post-compile.
2. Place strategic System.out.println() statements in the code - these are visible in the output window of the JDE while debugging.
3. When you get an uncaught exception, immediately disconnect from the debugger, go to the home screen on the BlackBerry, and type <ALT> LGLG. This invokes the system event log. You should locate your exception and view the complete stack trace in this log. You have to do this immediately, since the log only holds about 16K of data.
Hope this helps!
10-01-2008 08:47 PM
Good advice. Already doing #1 and #2. #3 is a reminder of the <ALT>LGLG trick, and it does show me that I'm getting an array out of bounds. Good info. Having disconnected from the debugger makes following the chain difficult; I'll spend some time digesting this. Thanks for the pointers.
Any idea why the debugger isn't able to act like it does in the simulator? Can't even show strings properly. I didn't do anything after compile other than sign the .cod file, load the app using desktop application loader, and attach the debugger.
10-01-2008 09:13 PM
Personally, I've been developing almost solely in the device OTA since I can't ( physically, LOL) attach my
device easily to my computer ( USB is in the back ). Anyway, this has worked quite well as I can email status
back for debug and I haven't run into any really wierd problems. With an automated build environment, the build
sign and upload is one "enter" and then off to surfing while I wait. It would be nice if you could mail back a
stack trace but I've learned work around this.
While I suppose there could be various build/setting problems( I wasn't sure what you meant about unkown classes, was your device complaining about your app missing classes?) , I would suggest, knowing nothing about you or your application, that this pervasive descrepancy between emulator
and real device could be caused by either memory or threading problems. Since java makes the former
almost impossible, I'd have to suspect thread neglect. Do you have various race conditions or hazards that aren't
interlocked or signalled? These could cause nominally reproducible but different results in emulator and device.
10-01-2008 09:18 PM
Native types seem to display OK (int, etc). Complex types I think you only get the address of the object. This is where the println comes in handy (the old "dirty footprint" debug method).
The 4.3.x version is (in my opinion) the worst of the lot, with many surprises and undocumented features. Consequently, there are more than a few versions of this OS out in the wild, and they all have some unique challenges (from carrier to carrier).
10-01-2008 09:54 PM
RexDoug, that is the behavior I am seeing. Works fine in the simulator but not on the device. Go figure.
Your previous post gave me the clues to get a little further, and the problem seems to be my code that isn't checking for error enough, as this problem never occurred in the simulator. It comes down directly to the problem I noted with messages "CMM: ClassicLit(1142) no sig from 0x33". Any idea what that means? It's causing me to not be able to read the file, though I have read it in the program before in a different inputStream from the same FileConnection. I'm not getting this message in the simulator and the 2nd inputStream seems to work fine there. Any ideas?
For the other suggestions from marchywka, thanks for the ideas. I've not got any threading in this app other than that done under the covers in the framework. If you've not attached your device to the debugger, you wouldn't see what I'm seeing in the debugger. You're doing your debugging prints via email and I do them via the debugger output window, so that's the same technique with different implementation. I'll play with your distribution technique, though. You send it as an attachment in email? Do you send just the cod file, or others as well?
Thanks for the continued assistance!
10-01-2008 10:11 PM - edited 10-01-2008 10:12 PM
You can ignore this "no sig from 0x33" - it means "no signature from signer 0x33". No 3rd party apps get this signature. It is not stopping you from doing anything.
Following up on marchywka's suggestion, always catch Throwable (rather than Exception). Catching Throwable triggers a stack trace to be stored in the event log.
10-02-2008 12:02 AM - edited 10-02-2008 12:03 AM
So it all comes down to when I open() the InputStream in the simulator I can use InputStream.available() to see how many bytes can be read, thus detecting eof. In the device, available() returns 0 and my eof code has a problem. So I can fix the EOF code.
Why does available() work differently in the simulator than in the device? Inquiring minds want to know!
10-02-2008 07:51 AM
A long time ago I stopped using available() in applets for that reason. Probably the easiest thing to do is just do your own
buffering on a separate thread and never call available() on an unknown stream.
I have been uploading essentially everything but AFAIK all I need is cod and jad.
Once you get rid of the gui, things get a lot easier. Just having it open ties up a big chunk
of physical memory making checking your mail becomes an adventure in VM.