BUG Community

Welcome! Log In

Forums BUGbase Menu becomes unresponsive

Subscribe to Menu becomes unresponsive  6 posts, 2 voices

Log in to reply to this topic
 
May 12, 2008 9:54pm
Medium Bug Labs team finsprings 268 posts

I’ve noticed that if I start to use the joystick shortly after the module icons have appeared, the menu will freeze. The joystick then won’t do anything until I reboot. The hotkeys also don’t appear to respond once it’s in this state (I had one bound to the shutdown command via my ByeBye app and it didn’t shutdown when I pressed it like it usually does).

If I wait for a while, I can navigate the menus fine.

May 13, 2008 9:46am
Medium Bug Labs team jconnolly 285 posts

finsprings
I've noticed that if I start to use the joystick shortly after the module icons have appeared, the menu will freeze. The joystick then won't do anything until I reboot. The hotkeys also don't appear to respond once it's in this state (I had one bound to the shutdown command via my ByeBye app and it didn't shutdown when I pressed it like it usually does).

If I wait for a while, I can navigate the menus fine.


Hey Dave,

I've tried to reproduce this with our BUGs here at the shop but I haven't been able to. Is there a more specific sequence of actions you take to produce this defect? Are there any applications on your BUG at boot time that may be listening to ButtonEvents?
May 13, 2008 9:50am
Medium Bug Labs team finsprings 268 posts

I had ByeBye and GPSLoggerSimpleGUI loaded but they only listen to Hotkeys. I also had Buger loaded, which creates a menuitem, so that might be pertinent. I don’t have any apps loaded that care about the joystick.

I’ve seen it where it will let me get into a menu but then freeze up. For example, I was going to gps_fix under the Locate module quite a bit, before I knew the LED would go green when it go a fix. So I’ve seen it freeze part way down to tree to gps_fix.

May 14, 2008 11:00pm
Medium Bug Labs team finsprings 268 posts

John, I've been trying to narrow this one down.

In each case I would start the bug and immediately begin pressing down repeatedly on the joystick, before it even finished booting.

I removed all the apps from my bug and restarted it. I was unable to get the menus to lock up.

I then added back in ByeBye, which listens for hotkey 4 and restarted it. Again, I was unable to get it to lock up.

I then added in GPSLoggerSimpleGUI and restarted it. This time, after quite a few presses of down that seemed to be going okay, I went into the Modules menu and go to the point where it said LCD on the display.

At this point it hung. Maybe a minute later it went back to showing the BUGlocate and BUGview icons (the only 2 modules I had connected), but it doesn't respond to any keys at this point. GPSLoggerSimpleGUI is working, and still updating GPS raw data on the screen. The cursor on the BUGview is still responsive. When I press any of the hotkeys, nothing happens: the antenna selection doesn't change in GPSLoggerSimpleGUI, and if I press hotkey 4 it does not shut down. The joystick doesn't do anything and neither does the button next to it.

top shows a process called cvm running at 14% constantly. I don't see anything interesting in the concierge.log. The bug responds via the USB ethernet connection just fine.

At this point I went in and did a "tail -f kern.log". Pressing hotkeys results in new output to the log such as:

May 15 02:46:42 localhost kernel: evbug.c: Event. Dev: bugnav, Type: 1, Code: 260, Value: 1
May 15 02:46:42 localhost kernel: evbug.c: Event. Dev: bugnav, Type: 0, Code: 0, Value: 0


so it would seem as if the buttons are responding at the OS level.

I then removed ByeBye from the bug and restarted it, so now it just has GPSLoggerSimpleGui on it. It hung again very quickly with me pressing just down on the joystick - it got to the scrolling Linux kernel display and stuck there. Again after a few seconds it went back to showing the icons but the buttons weren't responsive.


Is there any way I can go deeper on debugging the concierge/OSGi interaction with the buttons?

If a bug application gets a callback on an event, such as a button press, it's presumably being called in the context of a thread belonging to the IButtonEventProvider implementer. If an application locks that thread, or throws an exception within the callback, will that take out the IButtonEventProvider implementer altogether at the OSGi level? I know I've had similar problems in my own code, where the subject is notifying its observers of an event, and one of those observers does bad things in the callback.
May 15, 2008 10:19am
Medium Bug Labs team jconnolly 285 posts

Dave,

This reads like an excellent bugzilla entry. *hint hint* :wink:

I'm going to try to reproduce it today using your criteria. Preliminarily, I'm thinking that a lag in responsiveness early in the boot process may be due to the fact that OSGi is loading an application bundle that may take 30 seconds to load completely. You can verify this by checking /var/log/concierge.log and seeing how long it takes the OSGi to load (in my case ~14 seconds):

STARTING file:./com.buglabs.bug.module.camera.jar
[Thu May 15 10:00:31 GMT 2008] [INFO] Added modlet factory com.buglabs.bug.module.camera (0005) to map.
STARTING file:./com.buglabs.bug.module.lcd.jar
STARTING file:./com.buglabs.bug.module.motion.jar
[Thu May 15 10:00:31 GMT 2008] [INFO] Added modlet factory com.buglabs.bug.module.motion (0002) to map.
---------------------------------------------------------
Framework started in 14.316 seconds.
---------------------------------------------------------


To answer the question about more closely debugging ButtonEvent handling, the system.properties file in /opt/concierge on your BUG defines the loglevel in OSGi. The default setting (as of R1.1 of the rootfs) is logelevel=4, the most verbose. So, that won't get you anything more than what you see already in /var/log/concierge.log. Even though it's a dead end, you may want to see here for future reference:

http://concierge.sourceforge.net/properties.html

Our development team is working now on remote debugging capibilities and integrating it with eclipse, potentially allowing you to step through lines of code in real-time execution, much the way you can with the Virtual BUG.

I have definitely noticed intermittent irregularities in the behavior of ButtonEvent handling, namely in registering a buttonevent listener, and unregistering it. This may somehow be related.

The only thing I can think of right now to allow you to more closely inspect the workings of the IButtonEventProvider in real-time executioin would be to modify the source with lots of printlns and build it yourself. There are ways of doing this differently, without entirely rebuilding phoneME, rootfs, etc and I'll forward this thread to our development team for more elaboration.
May 15, 2008 11:06am
Medium Bug Labs team finsprings 268 posts

jconnolly
Dave,

This reads like an excellent bugzilla entry. *hint hint* :wink:

I would do that, John, but bugzilla uses an email address as your user account, and the one I used almost instantly got overwhelmed with spam, presumably because something evil is scraping your bugzilla webpages. I use sneakemail, so I just turned off that address and it went away, but of course it meant I couldn't get real emails from bugzilla either.

Anyway, I haven't gotten around to setting up another account in bugzilla, partially because I really dislike bugzilla's interface, and partially because I presumed it would just get spam-ridden again.
Log in to reply to this topic
Forums BUGbase Menu becomes unresponsive

Powered by Community Engine

Top
Login
Close