MuClient: Stability issues, SSL-related?

[GoogleCodeExporter]

I've tried MuClient on both an Archos A28 (Froyo, extremely limited RAM) and 
now an LG Optimus V phone (Froyo, 512MB RAM).

Unfortunately, on both devices, a few minutes of MUCKing can result in some 
sort of runaway behavior that nearly freezes the devices.  I've only been 
trying it with SSL connections, and with a couple losses of signal and 
reconnects per session due to being mobile/wireless.

On the Archos this seemed understandable, as it has so little RAM it can't 
reliably keep the keyboard(!) resident with MuClient or most other apps.

On the phone, this was more surprising, and I discovered the extent of the 
problem when a call came in and I was literally unable to answer it.  (In fact, 
the Launcher froze up and I was forced to pull the battery to reboot.)

I haven't yet looked at the memory usage of the MuClient process, let alone 
taken any steps to profile it.  I'm filing this mostly to find out if this is a 
known issue - and if not, I can investigate further and post the findings here.

Original issue reported on code.google.com by itsafl...@gmail.com on 1 Jun 2011 at 5:38

[GoogleCodeExporter]

I can't seem to reproduce the bad behavior on the LG today despite a fair bit 
of trying.  I'll give it another go on the ride home where loss-of-signal is 
far more frequent, but maybe this -is- the wrong tree for yesterday's phone 
freeze as I've caught "RF Signal Tracker" being more of a troublemaker as its 
dataset grows.

Instead, I've now managed to use MuClient long enough to discover the client 
seems to silently disconnect / close (when left idle? / not in focus?) and 
annihilates the active session and all its scrollback history.  That's a little 
suboptimal, but not nearly as bad as having the phone freeze. :)

Original comment by itsafl...@gmail.com on 2 Jun 2011 at 5:08

[GoogleCodeExporter]

I have no other reports of MuClient spinning and sucking up more resources than 
it should. If you can get a repro, I'd love to hear it, because that would be a 
very bad bug!

Android can kill any application at any time to make room for others, and 
MuClient takes no steps to prevent this from happening to it. Quickly checking 
something in an other app won't trigger it, but leaving any app unfocused for a 
long time will cause Android to evict it. So, yeah, that's pretty much by 
design.

Original comment by banderlabs on 7 Jun 2011 at 10:20

• Added labels: Application-MuClient, Component-Logic

[GoogleCodeExporter]

Interesting - I'm still very new to Android and didn't know about a timer-based 
(vs. OOM) eviction.

More interesting - while looking at the long list of apps that don't seem to 
get evicted even-if-I-wish-they-would - I noticed MuClient actually *was* still 
running from last week and returning to the 'World' did preserve the last 
session's scrollback!

This makes me wonder what the heck I was doing last week to form a belief that 
I kept losing the history.  I believe the operative word for this is "Durp."

...

And meanwhile, *while typing this* and sitting with the MuClient session 
freshly reconnected, I think I just went through the following:

a) Allowed display to go to sleep;
b) Resumed, noticed MuClient session still running happily;
c) Went to the home screen;
d) Went to launch another app (specifically one not running, happened to be the 
third-party 'Minutes Checker' for Virgin Mobile);
e) Watched phone freeze up on the home screen;

f) Had enough patience to find out the phone will eventually watchdog and 
reboot itself.**

I didn't *think* I could reproduce this until I just tried it again, in a 
sequence that I believe went as follows:

a) Start with freshly rebooted phone (and all the cruft that loads in the 
background at boot);
b) Run "Minutes Checker" with no problem;
c) Run MuClient and futz around some;
d) Flip back and forth between the home screen and MuClient, and "Minutes 
Checker" (now resident from the last run) without a problem;
e) Launch another something specifically *not* running: this time, the Kindle 
app;
f) Jackpot: Kindle loads, but near-immediately freezes up after showing the 
Table of Contents for the last thing I was reading (possibly at the first touch 
- it seems that I 'swiped' it over to a black screen before the phone froze up);
g) After what seems like a couple minutes, the phone returns to the 
Launcher/home screen - which is responding very noticeably slowly and then 
everything freezes up with an "Application Launcher has stopped responding" 
dialog, but input is lagging/not working, and eventually the phone again 
watchdog-reboots.**

So, now I try something different:

a) Start with rebooted phone;
b) Fire up MuClient, return to home screen;
c) Run a not-yet-resident app that doesn't touch the network - "GPS Test."
d) Curiously enough, GPS Test freezes but eventually I end up back at a fully 
responsive home screen - not sure if it died or my push of the Home key finally 
got through;
e) Check that MuClient is still running;
f) Try GPS Test again - this time it works fine.

and to make it more interesting:

g) Try Kindle again - oddly enough that works perfectly fine.
h) Make sure Kindle is killed, flip to MuClient, flip back, and... again, 
Kindle launches fine.
i) Realize the MuClient connection has been quiescent, so make some noise on 
the connected MUCK from a different machine while MuClient is in the background.
j) Try Kindle again: "Bingo," somewhere between there and returning to the home 
screen is another lockup (at which point "Launcher is not responding", I'm 
-able- to Force Quit, but then the phone's left frozen again).
h) Wait quite a while (see Digression), "eventually everything magically fixes 
itself", discover that, whatever portion of Android restarted itself, MuClient 
is still running and still connected and responsive!  Yikes.

[Digression: So after killing the Launcher and letting the phone sit frozen at 
what ended up another black screen - after a tap of the power button - for a 
number of minutes, holding the power button finally brought a glimmer of life 
in the form of the Shutdown / Airplane Mode? dialog flashing before, whups, the 
screen went back to sleep - possibly because I was still leaning or poking the 
power button.  Then, ignoring it, it returned to a home screen a couple minutes 
later, without any noticable 'reboot' occurring on the display.

**These can't have been full reboots, actually, since the terribly annoying 
Virgin Mobile splash screen and sound haven't played, and the phone still 
*thinks* it has an uptime of 164 hours.  The first two got me an animated 
'ANDROID' text while it fired back up, the last seemed to go from a 
not-responsive-to-anything black screen to having the Launcher suddenly pop 
back up and everything be 'normal.']

...

So... this could be much more definitive, but it appears that steps to try to 
reproduce this currently look like:

1. Connect somewhere with MuClient with SSL;
2. Switch to some other process, like the launcher, and make sure some chatter 
comes down the connection while MuClient is in the background;
3. Try to run an app that's not already resident, "especially" one that also 
wants to make an IP connection somewhere, "especially" one that probably also 
relies on whatever the SSL library is;
4. Hopefully things go haywire in an interesting way that's observable over an 
adb shell or such.

If there are particular log files that are likely to exist and be useful, let 
me know, I have adb available but not at the seat I'm at now.  Now that I know 
the above pretty much guarantees the SNAFU on *my device,* hopefully I'll find 
time to poke at it this week.

Manage Applications hasn't shown the process eating more than 116k at any 
particular time I've been able to get to Manage Applications.

After that last thrill ride of a not-really-a-reboot, the Running Services 
display shows "264MB+80MB in 22" available.  For whatever that's worth.  So it 
smells like it's not an OOM problem, but that's not very well-proven.

Original comment by itsafl...@gmail.com on 7 Jun 2011 at 11:40

[GoogleCodeExporter]

Immediately after typing the last of the above (where Everything Fixed Itself 
and MuClient remained running all that time):  Watch the phone's display go to 
sleep, wake it up for no good reason, swipe to unlock, wait a long ~10 seconds 
for the home screen to display, find out the home screen is being unresponsive 
again, wait about a minute, see the "ANDROID" splash screen come up, unlock and 
find that this time, for whatever reason, MuClient got killed.

And just to keep on track, MuClient seems to be the one variable that gets the 
phone into this mess, though it could be interacting with something else I have 
installed.

Original comment by itsafl...@gmail.com on 7 Jun 2011 at 11:49

[GoogleCodeExporter]

Fixed in MuClient v1.01!

Original comment by banderlabs on 15 Jun 2011 at 8:44

• Changed state: Fixed