Re: [Logicmail-devel] lockup issue with 1.9.0 builds

[Derek K. <dko...@lo...>]

Ahh, the joys of you being on the west coast (and me on the east coast), 
and us both doing most of this after work...  Puts a day lag between us 
:-)  Though it reminds me of when I spent a summer durring college in San 
Diego, and was delighted that I could still chat /w my night-owl 
east-coast friends and still get to bed at a reasonable hour.

On Tue, 1 Sep 2009, Chris Seawood wrote:
> Yeah, I'm a firm believer in eating your own dogfood.  Plus, everyone
> was raving about 1.9.0 in a previous thread and there were binary builds
> so I had to try it out. :-)

I'm very close to that point myself with trunk (1.9).  My main hesitation 
had to do with the fact that I haven't put much effort yet into ironing 
out all the error conditions that can arise from a flaky network, which is 
a mostly non-existant problem at home.  I do periodically load the lastest 
build onto my older 8820 and test it over Wi-Fi, however.  Though right 
now I'm discovering some random/minor UI quirks as a side-effect of my 
attempt to support Storm and conventional UIs from the same source tree. 
Hopefully those will be ironed out soon enough, and there aren't many of 
them.  (I just wish it was less annoying to switch back and forth in the 
dev tools.)

> The first 1.9.0 build was your binary build from last week (8/26?).  My
> local builds are done using ant.
The build server (obviously) uses ant as well, so they should match up 
fairly well.  Though anything's possible.  Mixing and matching Eclipse and 
Ant builds on a real device could very well cause entry-point issues, 
however.

> I just ran my local build in the simulator and it crashes with the
> unhandled exception error when LogicMail attempts to get my folder list.
>
> I can't figure out how to copy the stack trace but essentially, it looks
> something fails when ImapProtocol::executeList tries to update the
> status of the MailProgressHandler.  When I commented out all of those
> calls, then the app stopped crashing at that point.

The inability to get your usual Java-style stack trace has to be my #1 pet 
peeve in the world of BlackBerry software development.  Especially, of 
course, when the "user" isn't willing/able to run the app in the simulator 
from a development IDE.

That being said, the code you're hitting is fairly recent.  My wild guess 
would be that I'm incorrectly calculating something in regards to progress 
reporting, or you're hitting some strange condition when it tries updating 
the status bar in the GUI.  I actually did some work this past weekend on 
how the status bar gets displayed, so I'd make sure you have that before 
moving forward.  Once you're past that point, some more direct debugging 
would be extremely helpful.  The Eclipse debugger makes it fairly easy to 
see what line of code the exception was thrown from, usually, though not 
necessarily what on the line caused the error.  So it never hurts to set a 
breakpoint right before it and step through.

I'll have to test some of that later myself, of course.  The output of the 
folder listing is one of those items that gets cached, so I'm probably not 
re-running that code very often.

P.S. I recently realized that if I keep focusing 100% on nitpick issues 
(of which I'm aware of plenty, and have been keeping a to-do list) then 
I'm never going to make real progress, so I'm currently focusing on 
the infrastructure code for offline message caching.  (that and connection 
management being the two key big-ticket items necessary for release...)
Someday I'll figure out a way of making my TO-DO list more visible, since 
its a more convenient way to work right now than Trac tickets.  (maybe if 
Tomboy Notes ever stabilizes their web service project)

-- 
----------------------------
  Derek Konigsberg
  dko...@lo...
----------------------------