09-11-2008 07:06 AM - edited 09-11-2008 09:22 AM
I've just started to test my application with the simulators that come with JDE 4.5.0 and JDE 4.6.0, and it appears that the implementation of ZlibOutputStream has had some flaws introduced since 4.3 (which is what I've been developing on, I've never seen any problems of this kind with either the simulator that comes with JDE 4.3.0 or an 8120 running some flavour of 4.3). On the 9000 simulator, most of the time data is sent correctly but occasionally some data will cause the program at the other end of the connection (using standard Zlib) to fail on the "inflate" call with an error code which indicates either data doesn't conform to the Zlib format, or the Adler32 checksum is corrupted. On the 8310 simulator, this error happens pretty much as soon as the connection is established, whereas on the 9000 often things will run okay for a minute or more before this error appears.
If I switch the program to not use Zlib, but do everything else the same, both ends run without a hitch, so I am convinced the problem is in ZlibOutputStream. Has the implementation of this been changed since 4.3? For what it's worth, the viewer end codebase is extremely mature and stable (part of an application which has been downloaded 10 million+ times) so I am pretty much ruling out that the Zlib implementation or other parts on the client end could have issues.
Edit: I've just checked and confirmed that the 22.214.171.124 8220 simulator which has just been released also exhibits this problem.
09-11-2008 03:34 PM
I've run some tests reading in a file from the micro SD card, running it through a ZLibOutputStream, saving it back to the micro SD card and then reading it back in using a ZLibInputStream and have seen any errors.
This differs from your test of using a remote server, but the results should be similar. What constructor and values are you using for ZLibOutputStream?
09-12-2008 05:33 AM
I'm using the constructor like this:
new ZLibOutputStream(<my JavaOutputStream object>, false, 15,9)
I guess these values being at the maximum in terms of compression effort and memory window size could stress the code somewhat, but these same values work fine on 4.3. The code runs perfectly, albeit pretty slowly, on an 8120 so I would have thought on a Bold I could set the values to as high as I wanted without problems. When you mention that you've read it back in using ZlibInputStream, is it possible there have been modifications to both the in and output streams such that they are compatible with each other, but not with an external zlib library? This seems hugely unlikely, obviously, but I can't think of any reason why the exact same code in different versions of the simulator would produce problems.
This might be like a few of the other issues I've seen developing my project, in that it's pretty unreliable to find an exact way to reproduce it, and small test cases run without problems. My company (RealVNC) has had talks with Mike Kirkup and Brad Hanna recently, and we are in the process of joining the ISV alliance, so once that is done (I imagine within the next month or so) and NDAs etc are in place I'm sure it would be no problem for us to provide RIM with the source of the program, to help get the issue tracked down. I appreciate your efforts in helping at this point though, thankyou!
09-12-2008 11:19 AM
I tried with those values as well. It did take longer as expected, but I was still able to read back the file I had created in the version 4.5.0 and 4.6.0 BlackBerry Simulators.
It may be a "bigger picture" issue as you describe.
09-17-2008 07:45 AM - edited 09-17-2008 07:51 AM
Fortunately this bug appears not to be the case with either of the actual 9000 devices I have (running 126.96.36.199). I have two, and they've both been keeping a connection live (using ZLibOutputStream) for several hours and counting now with no problems. Either this is some simulator specific problem, or this was a bug in 188.8.131.52 which was fixed sometime before 184.108.40.206 and then re-introduced for 220.127.116.11. I'm not sure.. but either way it appears we are able to demo our software reliably on Bold devices which is great.
I would put some time into trying to flash the device with different OS versions to see if I can find a version/versions which exhibit the problem on the device, but I'm only working here for 2 more days and it's more crucial that I leave the company with a product ready to demo at an upcoming trade show. Besides I'm not sure if any of the OS versions in the simulators are available for download anywhere. Regardless though, good job to the Bold team, this is a huge step up in power and reliability from everything else I've been using.
09-17-2008 01:43 PM