BlackBerry: "Application is not responding; process terminated" because of UiApplication.getUiApplication().popScreen()?

Asked 27/7, 2011 at 18:6 Answered 30/6, 2012 at 14:57

Solved blackberry blocking blackberry-simulator

I have a Blackberry application which, when run in some emulators with touch support (ex: 9500, 9520, 9530, 9550), terminates with:

"Application is not responding; process XPTO terminated"

Using logs, I found out that it seems like the application is stopping in a class where I asynchronously make HTTP requests: something like:

public class LoadingFullScreen extends FullScreen implements Runnable {

    private Thread actionThread = null;

    protected void onDisplay() {
        actionThread = new Thread(this);
        actionThread.start();
    }

    protected void onUndisplay() {
        if(actionThread != null && actionThread.isAlive()) {
            actionThread.interrupt();
        }
    }

    public void run() {
        //make http requests - this is done successfully

        synchronized(Application.getEventLock()) {
                Screen active = UiApplication.getUiApplication().getActiveScreen();
                if (active instanceof LoadingFullScreen) {
                    Logger.debug("LoadingFullScreen popping screen"); //this appears in logs
                    UiApplication.getUiApplication().popScreen(active);
                    Logger.debug("LoadingFullScreen screen popped"); //this never appears in logs
                }
        }
    }
}

I launch this screen with UiApplication.getUiApplication().pushModalScreen(new LoadingFullScreen())

In the logs I can see:

[0.0] Wed Jul 27 17:53:06 GMT 2011 - DEBUG: LoadingFullScreen popping screen
[0.0] JVM: bklt[1] @163148: JBSC on=0
[0.0] JVM: bklt[1] @163148: SC 0
[0.0] JVM: bklt[1]: setTimeout 30
[0.0] Application XPTO(212) is not responding; process terminated

It seems like UiApplication.getUiApplication().popScreen() is blocking the application, and so the OS kills the application, but why?

EDIT:
I have also tried using

UiApplication.getUiApplication().invokeLater(new Runnable() {...} };

instead of synchronized(Application.getEventLock()) {...} but I have the exact same result

EDIT 2:
I have also tried active.close() instead of UiApplication.getUiApplication().popScreen(active); but I have the exact same result

EDIT 3: Using javaloader I got this kind of stacktrace from the emulator:

guid:0x9C3CD62E3320B498 time: Thu Jul 28 15:02:50 2011  severity:0 type:3 app:Java Exception data:
    ForcedStackTraceException
    net_rim_services_impl(4) 27 2 0x1030B000
    net_rim_os-3(4BEF0320)
     HttpConnectionManager$CleanupThread
     run
     0x3B09
guid:0x9C3CD62E3320B498 time: Thu Jul 28 15:02:50 2011  severity:0 type:3 app:Java Exception data:
    ForcedStackTraceException
    XPTO(247) 60 4 0x124A0400
    net_rim_cldc-16(4BEEF8A5)
     TextField
     getFocusRect
     0x2A61
    net_rim_cldc-12(4BEEF8A5)
     Manager
     getFocusRect
     0x717
    net_rim_cldc-12(4BEEF8A5)
     Manager
     getFocusRect
     0x717
    net_rim_cldc-12(4BEEF8A5)
     Screen
     getFocusRect
     0x9AF2
    net_rim_cldc-12(4BEEF8A5)
     Screen
     callOnExposed
     0x9D16
    net_rim_cldc-13(4BEEF8A5)
     UiEngineImpl
     <private>
     0x9007
    net_rim_cldc-13(4BEEF8A5)
     UiEngineImpl
     removeScreen
     0x7D08
    net_rim_cldc-12(4BEEF8A5)
     Screen
     close
     0x6B66
    XPTO-8(4E316B06)
     LoadingFullScreen$1
     run
     0x34D5
    net_rim_cldc-8(4BEEF8A5)
     Application
     dispatchInvokeLater
     0x1A87
    net_rim_cldc-8(4BEEF8A5)
     Application
     <private>
     0x2809
    net_rim_cldc-8(4BEEF8A5)
     Application
     processNextMessage
     0x1AEF
    net_rim_cldc-9(4BEEF8A5)
     ModalEventThread
     run
     0xBE4F
guid:0x9C3CD62E3320B498 time: Thu Jul 28 15:02:50 2011  severity:0 type:3 app:Java Exception data:
    ForcedStackTraceException
    XPTO(247) 30 2 0x139DA800
    net_rim_cldc(4BEEF8A5)
     Object
     wait
     0x9922
    net_rim_cldc-8(4BEEF8A5)
     Application
     startModalEventThread
     0x1EB8
    net_rim_cldc-13(4BEEF8A5)
     UiEngineImpl
     addScreenModal
     0x83F4
    net_rim_cldc-13(4BEEF8A5)
     UiEngineImpl
     pushModalScreen
     0x674E
    net_rim_cldc-13(4BEEF8A5)
     UiApplication
     pushModalScreen
     0x62B0
    XPTO-8(4E316B06)
     MyBaseScreen
     <private>
     0x3AA6
    XPTO-8(4E316B06)
     MyBaseScreen
     openTheModalScreenFunction
     0x382C
    XPTO-8(4E316B06)
     MyBaseScreen$4
     fieldChanged
     0x4271
    net_rim_cldc-11(4BEEF8A5)
     Field
     fieldChangeNotify
     0x160B
    net_rim_cldc-16(4BEEF8A5)
     TextField
     replace
     0x7A5
    net_rim_cldc-16(4BEEF8A5)
     TextField
     inputMethodTextChanged
     0x24E1
    net_rim_cldc-15(4BEEF8A5)
     PasswordEditField
     inputMethodTextChanged
     0x4F26
    net_rim_cldc-27(4BEEF8A5)
     IMContext
     dispatchInputMethodEvent
     0x1E00
    net_rim_tid-4(4BEEF8E1)
     SLInputMethod
     sendComposedText
     0x5CA1
    net_rim_tid-4(4BEEF8E1)
     SLInputMethod
     sendComposedText
     0x5BD1
    net_rim_tid_fastEuropean(4BEF034C)
     FastEuropeanInputMethod
     sendComposedText
     0x48E1
    net_rim_tid_fastEuropean(4BEF034C)
     FastEuropeanInputMethod
     dispatchConversionEvent
     0x43E3
    net_rim_tid-4(4BEEF8E1)
     SLInputMethod
     dispatchKeyEvent
     0x5309
    net_rim_tid-4(4BEEF8E1)
     SLInputMethod
     dispatchEvent
     0x63CA
    net_rim_tid_fastEuropean(4BEF034C)
     FastEuropeanInputMethod
     dispatchEvent
     0x426E
    net_rim_cldc-27(4BEEF8A5)
     InputContext
     dispatchEvent
     0x3E15
    net_rim_cldc-27(4BEEF8A5)
     IMContext
     dispatchEvent
     0x21DE
    net_rim_cldc-11(4BEEF8A5)
     Field
     dispatchEvent
     0x3739
    net_rim_cldc-16(4BEEF8A5)
     TextField
     dispatchEvent
     0x30F6
    net_rim_cldc-27(4BEEF8A5)
     EventHandler
     <private>
     0x1460
    net_rim_cldc-27(4BEEF8A5)
     EventHandler
     processKeyEvent
     0x1A79
    net_rim_cldc-16(4BEEF8A5)
     TextField
     processKeyEvent
     0x37F6
    net_r

EDIT 4: I have tried to move the run() method in LoadingFullScreen to a new Runnable class, as I was told that having LoadingFullScreen implement Runnable could cause problems when that class is shown as a modal screen.
However, I had no luck and I still have the same problem.
Any ideas?

EDIT 5: Solved here: BlackBerry: "Application is not responding; process terminated" because of UiApplication.getUiApplication().popScreen()?

Lyallpur answered 27/7, 2011 at 18:6 Comment(4)

Are you using any overrides on "active" e.g. onClose()? – Analemma 28/7, 2011 at 9:46

Hi Ray. I am overriding onDisplay and onUndisplay. I am editing the post, adding those methods – Lyallpur 28/7, 2011 at 10:39

I launch this screen with UiApplication.getUiApplication().pushModalScreen(new LoadingFullScreen()), does it have any influence? – Lyallpur 28/7, 2011 at 11:43

modal is used to get a response from the screen. E.g. a popup screen that allows the user to choose something, I don't think it would cause this problem. You should probably change it to pushScreen() because you don't need a response, I can tell this because you reference it as (new LoadingFullScreen()) E.g. to get a response you would use myLoadingFullScreenInstance.someGetter(). onDisplay, onUndisplay were deprecated replaced by onUiEngineAttached(true|false) Try using those. Also try wait for the thread to have definitely ended b4 pop. I can't explain why that would only break touch devices – Analemma 1/8, 2011 at 13:25

As none of the answers solve the problem, I am posting here the solution I reached with help from other forum (http://supportforums.blackberry.com/t5/Java-Development/Application-is-not-responding-process-terminated-because-of/m-p/1234573#M168285)

I didn't find it relevant, but it seems that the way I was calling LoadingFullScreen matters:

public void fieldChanged(Field field, int context) {
    LoadingFullScreen loading  = new LoadingFullScreen();
    System.out.println("calling pushModalScreen"); //this was showing up in logs
    UiApplication.getUiApplication().pushModalScreen(loading);
    System.out.println("pushModalScreen done"); //this wasn't showing up in logs    
}

It turns out the emulators/devices I mentioned have support for 'SureType'. "That means they do some off things when you press a key. Typically, they will attempt to display a 'choice' for the user, becuase each key has two options. becuase you are doing a pushModal in the FieldChanged method, you are blocking this. And this I think is what it is getting upset about."

So the solution was to change the way this instead:

public void fieldChanged(Field field, int context) {
    if ( context != FieldChangeListener.PROGRAMMATIC ) {
        UiApplication.getUiApplication().invokeLater(new Runnable() { 
            public void run() {
                LoadingFullScreen loading  = new LoadingFullScreen();
                UiApplication.getUiApplication().pushModalScreen(loading);          
            }
        }
    }
}

Lyallpur answered 2/8, 2011 at 11:12 Comment(0)

I remember that once I had almost same kind of problem. Whenever I tried to pop screen by acquring lock of Event thread, the app would crash. SO instead of getting hold(lock) of Event thread, try synchronizing on Event thread using invokeLater().

UiApplication.getUiApplication().invokeLater(new Runnable()
{  
   public void run()
   {  

   }  
});

Disinterest answered 27/7, 2011 at 18:55 Comment(7)

Thanks for the answer. I tried that, but I have the exact same problem. I edited the original post to reflect that – Lyallpur 28/7, 2011 at 8:52

I might be wrong with my this suggestion. I'm not expert on Threads. But thought this might be problem Looking at your code, I noticed that you implement Runnable on UI class (FullScreen). And you push this scree using UiApplication.getUiApplication().pushModalScreen(). So you LoadingFullScreen is on now Event thread. When screen is pushed to display stack, you create a new thread and put LoadingFullSCreen runnable on this thread which will execute run(). In this thread, you attempt to popScreen which created this thread. I suspect some problem here. – Disinterest 28/7, 2011 at 22:27

I would suggest to create a new class (something like ConnectNetwork ) which implements Runnable. Cut method run() of LoadigFullScreen and paste it into new class. Now put this new runnable class on thread which will be created as usual. One more thing, use onUiEngineAttached() instead of onDisplay() and onUnDisplay(). Later methods have been deprecated from recent OSes. I hope this is the problem. – Disinterest 28/7, 2011 at 22:33

Hi @ indusBull. Infortunately, it didn't work. I moved the run() method to a new Runnable class, but I got the same problem :S – Lyallpur 29/7, 2011 at 13:43

Do you still start the thread from the same class when screen is attached? I'm asking because you pop this screen from the same thread. And you attempt to interrupt thread when it is trying to pop the screen which might be conflicting. – Disinterest 29/7, 2011 at 14:10

Hi again @indusBull. I didn't exactly understand your last question, but I even removed the whole onDisplay/onUndisplay/onUiEngineAttached stuff and started the thread in the class constructor and I noticed that I have a different issue: the invokeLater's run block is not called – Lyallpur 29/7, 2011 at 14:28

@Lyallpur let us continue this discussion in chat – Disinterest 29/7, 2011 at 15:29

I didn't find it relevant, but it seems that the way I was calling LoadingFullScreen matters:

public void fieldChanged(Field field, int context) {
    LoadingFullScreen loading  = new LoadingFullScreen();
    System.out.println("calling pushModalScreen"); //this was showing up in logs
    UiApplication.getUiApplication().pushModalScreen(loading);
    System.out.println("pushModalScreen done"); //this wasn't showing up in logs    
}

So the solution was to change the way this instead:

public void fieldChanged(Field field, int context) {
    if ( context != FieldChangeListener.PROGRAMMATIC ) {
        UiApplication.getUiApplication().invokeLater(new Runnable() { 
            public void run() {
                LoadingFullScreen loading  = new LoadingFullScreen();
                UiApplication.getUiApplication().pushModalScreen(loading);          
            }
        }
    }
}

Lyallpur answered 2/8, 2011 at 11:12 Comment(0)

Assuming smth is wrong (assuming there's a RIM bug) with UiApplication.getUiApplication().popScreen() here is just an idea to try:

Instead of UiApplication.getUiApplication().popScreen(active); try to call active.close().

Stigmatic answered 28/7, 2011 at 9:3 Comment(2)

Hi, thanks for the suggestion. However, I get exactly the same behaviour. I edited the original post to reflect that – Lyallpur 28/7, 2011 at 9:35

Hm.. I believe to what MusiGenesis and you say. However this is very unexpected to me. I've been successfully using UiApplication.getUiApplication().popScreen() on Storms for a couple of years. Probably there should be some other conditions (which my app does not have) for this bug to show up. Or maybe the bug shows up on some specific OS builds. – Stigmatic 28/7, 2011 at 10:20

i believe this is because ui thread and ur thread created are not communicating properly. you can use this following code.

UiApplication.getUiApplication().invokeLater(new Runnable()
{  
   public void run()
   {  

   }  
});

Maidenhair answered 1/8, 2011 at 18:52 Comment(1)

Thanks for the tip, but as I told in the first EDIT, I had already tried that and it didn't work – Lyallpur 2/8, 2011 at 10:55

I was having similar strange issues with a popup screen I implemented. It turned out that I had 2 different methods trying to pop the screen at the same time. This led to the error.

I ended up creating a static helper method that I now use to close my screens, which checks if the screen is actually displayed before closing it.

Posted here in case it helps someone:

/**
 * Convenience method to request a screen to close & pop it from the display
 * stack. This method handles the UI threading issues.
 * 
 * @param screen
 *        {@link Screen} to be closed.
 */
public static void closeScreen(final Screen screen)
{
    UiApplication.getUiApplication().invokeLater(new Runnable()
    {

        public void run()
        {
            if (screen.isDisplayed())
            {
                screen.close();
            }
        }
    });
}

Gelatin answered 18/1, 2012 at 11:16 Comment(0)

I have experienced something similar to this. I have a callback (invoked from another thread) in which processing happens, and informs the user of the indication of processing via Status and was using code like this:

UiApplication.getUIApplication.invokeLater(new Runnable(){
   public void run(){
     Status.show("....");
   }
});

And was getting near identical errors as the OP.

I realized then, because the callback was being executed multiple times, ALL of those Runnables were being queued up and hence "Too many threads" followed by a nice crash!

The solution:

UiApplication.getUIApplication.invokeAndWait(new Runnable(){
   public void run(){
     Status.show("....");
   }
});

That will block until the event queue gets cleared making way for more Status showing up.

Since its on a thread, it does not matter and thus a nice compromise.

End result: No more nasty crashes and no spurious messages in the event log.

To the OP: You may have to restructure slightly how you're informing the end user on notification of processing the UI logic in order not to exhaust the threading pool.

BTW, it should be noted - this is on BB 4.5 :)

Gratifying answered 30/6, 2012 at 14:57 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags