Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » DSDP - Mobile Tools for Java (MTJ) » startApp threw an Exception
startApp threw an Exception [message #25143] Mon, 12 January 2009 00:13 Go to next message
Eclipse User
Originally posted by: news.s237965939.online.de

In the emulator (Motorola SDK) I get the exception described below. I
opened the debugger preferences but when i check the option "Suspend
execution on uncaught exceptions" I get this message

There are some problems with your Java Debug settings for MTJ debug. Do
you want to fix them?
The "Suspend execution on uncaught exceptions" option must not be
checked on the java debug preference page.

So how can I catch this exception to localize it's reason? BTW, I just
checked the Sun WTK: same error.

TIA,
Hans

startApp threw an Exception
java.lang.IllegalStateException
java.lang.IllegalStateException
at javax.microedition.lcdui.Form.append(Unknown Source)
at UserInterface.ScaleSelectForm.<init>(ScaleSelectForm.java:43)
at UserInterface.MidiExample.startApp(MidiExample.java:62)
at javax.microedition.midlet.MIDletProxy.startApp(Unknown Source)
at com.sun.midp.midlet.Scheduler.schedule(Unknown Source)
at com.motorola.moja.jsr118.ApplicationManager.runLocalClass(Un known
Source)
at com.motorola.moja.jsr118.ApplicationManager.runApp(Unknown Source)
at com.motorola.moja.emulator.Emulator.<init>(Unknown Source)
at com.motorola.moja.emulator.Emulator.main(Unknown Source)
Re: startApp threw an Exception [message #25184 is a reply to message #25143] Mon, 12 January 2009 00:42 Go to previous messageGo to next message
Eclipse User
Originally posted by: news.s237965939.online.de

I forgot something important: The error happens when I select Pause and
then resume. The application just terminates. pauseApp() does nothing.

Hans
Re: startApp threw an Exception [message #25225 is a reply to message #25184] Mon, 12 January 2009 13:41 Go to previous messageGo to next message
David Marques is currently offline David Marques
Messages: 80
Registered: July 2009
Member
Hello Hans,

The pause/resume buttons on the debug view will pause/resume the emulator
process. They are not related to the pauseApp/resumeApp Java ME events of
the MIDlet Suite life cycle. Every emulator has it's own way to simulate
pause/resume events.

Regarding localizing an error, on the console output some stack trace
entries have links that point to the lines in the source code.

Regards,

David Marques
Re: startApp threw an Exception [message #25263 is a reply to message #25143] Mon, 12 January 2009 14:28 Go to previous messageGo to next message
Eclipse User
Originally posted by: news.s237965939.online.de

Hans-J. Ude wrote:
>
> So how can I catch this exception to localize it's reason? BTW, I just
> checked the Sun WTK: same error.

I've found the problem myself. In startApp() I've created some objects
like forms with 'xyzForm xyz = new xyzForm("XYZ")' and I didn't know
that if I click Resume after Pause then startApp() would be called
again, thus crashed. I've moved all object creation into the constructor
of the midlet now and everything is alright. But the basic question
remains, how can such exceptions be caught in the debugger?

Hans
Re: startApp threw an Exception [message #25302 is a reply to message #25225] Mon, 12 January 2009 14:35 Go to previous messageGo to next message
Eclipse User
Originally posted by: news.s237965939.online.de

David Marques schrieb:
> Hello Hans,
>
> The pause/resume buttons on the debug view will pause/resume the
> emulator process. They are not related to the pauseApp/resumeApp Java ME
> events of the MIDlet Suite life cycle. Every emulator has it's own way
> to simulate pause/resume events.

Thanks David. I meant the pause/resume in the emulator menu, not the
debugger. These commands simulate an incoming call. But I resolved the
issue as I descibed in my other post in this thread.

Hans
Re: startApp threw an Exception [message #25342 is a reply to message #25263] Mon, 12 January 2009 15:02 Go to previous messageGo to next message
David Marques is currently offline David Marques
Messages: 80
Registered: July 2009
Member
Hello Hans,

I don't clearly understand what you mean with "how can such exceptions be
caught in the debugger?".

Normally when there is an exception the first place to track the problem
is the stack trace as the one you attached on the other post:

startApp threw an Exception
java.lang.IllegalStateException
java.lang.IllegalStateException
at javax.microedition.lcdui.Form.append(Unknown Source)
at UserInterface.ScaleSelectForm.<init>(ScaleSelectForm.java:43)
at UserInterface.MidiExample.startApp(MidiExample.java:62)
at javax.microedition.midlet.MIDletProxy.startApp(Unknown Source)
at com.sun.midp.midlet.Scheduler.schedule(Unknown Source)
at com.motorola.moja.jsr118.ApplicationManager.runLocalClass(Un known
Source)
at com.motorola.moja.jsr118.ApplicationManager.runApp(Unknown Source)
at com.motorola.moja.emulator.Emulator.<init>(Unknown Source)
at com.motorola.moja.emulator.Emulator.main(Unknown Source)

MTJ adds links to the stack trace on the console that points to the source
code lines. Looking at your stack trace I have identified that the error
is on a call to javax.microedition.lcdui.Form.append method. Part of the
method documentation says: "IllegalStateException - if the item is already
owned by a container." So I believe that the problem is that you are
adding an Item more than once. Adding break points before the append()
method call will clear your doubts.

Regards,

David Marques
Re: startApp threw an Exception [message #25462 is a reply to message #25342] Mon, 12 January 2009 17:28 Go to previous messageGo to next message
Eclipse User
Originally posted by: news.s237965939.online.de

Hello David,
see below...

David Marques wrote:
> Hello Hans,
>
> I don't clearly understand what you mean with "how can such exceptions
> be caught in the debugger?".

I mean that the debugger would suspend execution in that moment at that
source line where the exception takes place.

[Stack trace ...]

> MTJ adds links to the stack trace on the console that points to the
> source code lines. Looking at your stack trace I have identified that
> the error is on a call to javax.microedition.lcdui.Form.append method.
> Part of the method documentation says: "IllegalStateException - if the
> item is already owned by a container." So I believe that the problem is
> that you are adding an Item more than once. Adding break points before
> the append() method call will clear your doubts.

These are linenumbers indeed in the stack trace. Googeling around for
that problem i found in a forum someone claiming those were byte offsets
in the .class files, which would be rather useless. Obviousley wrong
information. But since these are really line numbers this kind of
post-mortem-debugging is useful for locating the error.

thanks again,
Hans
Re: startApp threw an Exception [message #25657 is a reply to message #25462] Tue, 13 January 2009 00:29 Go to previous message
Eclipse User
Originally posted by: craigjunk.setera.org

Hans,

A couple of comments below...

Hans-J. Ude wrote:
> Hello David,
> see below...
>
> David Marques wrote:
>> Hello Hans,
>>
>> I don't clearly understand what you mean with "how can such exceptions
>> be caught in the debugger?".
>
> I mean that the debugger would suspend execution in that moment at that
> source line where the exception takes place.
>

Unfortunately, while this is supported by the Eclipse debugger, it is
not generally supported by the JavaME emulators. The JavaME emulators
run what is referred to as a KVM (kilobyte virtual machine) that is
smaller than a full JavaSE virtual machine. There is a debugging proxy
that sits in front of the KVM to provide the standard JDWP debugger
protocol for Eclipse to debug the emulator. Unfortunately, somewhere in
the combination of the KVM and the debugger proxy, there are features
that are not implemented or supported. Thus, you can't do that. It is
also the reason that MTJ has some special requirements for debugger
settings. (It is also the reason I had to convince the Java debugger
gurus to accept an ugly patch that hacked the debugger for KVM
connections a few years ago <grin>)

> [Stack trace ...]
>
>> MTJ adds links to the stack trace on the console that points to the
>> source code lines. Looking at your stack trace I have identified that
>> the error is on a call to javax.microedition.lcdui.Form.append method.
>> Part of the method documentation says: "IllegalStateException - if the
>> item is already owned by a container." So I believe that the problem
>> is that you are adding an Item more than once. Adding break points
>> before the append() method call will clear your doubts.
>
> These are linenumbers indeed in the stack trace. Googeling around for
> that problem i found in a forum someone claiming those were byte offsets
> in the .class files, which would be rather useless. Obviousley wrong
> information. But since these are really line numbers this kind of
> post-mortem-debugging is useful for locating the error.
>
> thanks again,
> Hans

You are correct that those are byte code offsets. I believe we merged a
patch from another developer that should allow you to click on those
links and get to the correct line number. If that isn't working, there
may be a bug.

Craig
Re: startApp threw an Exception [message #569975 is a reply to message #25143] Mon, 12 January 2009 00:42 Go to previous message
Eclipse User
Originally posted by: news.s237965939.online.de

I forgot something important: The error happens when I select Pause and
then resume. The application just terminates. pauseApp() does nothing.

Hans
Re: startApp threw an Exception [message #569996 is a reply to message #25184] Mon, 12 January 2009 13:41 Go to previous message
David Marques is currently offline David Marques
Messages: 80
Registered: July 2009
Member
Hello Hans,

The pause/resume buttons on the debug view will pause/resume the emulator
process. They are not related to the pauseApp/resumeApp Java ME events of
the MIDlet Suite life cycle. Every emulator has it's own way to simulate
pause/resume events.

Regarding localizing an error, on the console output some stack trace
entries have links that point to the lines in the source code.

Regards,

David Marques
Re: startApp threw an Exception [message #570052 is a reply to message #25143] Mon, 12 January 2009 14:28 Go to previous message
Eclipse User
Originally posted by: news.s237965939.online.de

Hans-J. Ude wrote:
>
> So how can I catch this exception to localize it's reason? BTW, I just
> checked the Sun WTK: same error.

I've found the problem myself. In startApp() I've created some objects
like forms with 'xyzForm xyz = new xyzForm("XYZ")' and I didn't know
that if I click Resume after Pause then startApp() would be called
again, thus crashed. I've moved all object creation into the constructor
of the midlet now and everything is alright. But the basic question
remains, how can such exceptions be caught in the debugger?

Hans
Re: startApp threw an Exception [message #570162 is a reply to message #25225] Mon, 12 January 2009 14:35 Go to previous message
Eclipse User
Originally posted by: news.s237965939.online.de

David Marques schrieb:
> Hello Hans,
>
> The pause/resume buttons on the debug view will pause/resume the
> emulator process. They are not related to the pauseApp/resumeApp Java ME
> events of the MIDlet Suite life cycle. Every emulator has it's own way
> to simulate pause/resume events.

Thanks David. I meant the pause/resume in the emulator menu, not the
debugger. These commands simulate an incoming call. But I resolved the
issue as I descibed in my other post in this thread.

Hans
Re: startApp threw an Exception [message #570175 is a reply to message #25263] Mon, 12 January 2009 15:02 Go to previous message
David Marques is currently offline David Marques
Messages: 80
Registered: July 2009
Member
Hello Hans,

I don't clearly understand what you mean with "how can such exceptions be
caught in the debugger?".

Normally when there is an exception the first place to track the problem
is the stack trace as the one you attached on the other post:

startApp threw an Exception
java.lang.IllegalStateException
java.lang.IllegalStateException
at javax.microedition.lcdui.Form.append(Unknown Source)
at UserInterface.ScaleSelectForm.<init>(ScaleSelectForm.java:43)
at UserInterface.MidiExample.startApp(MidiExample.java:62)
at javax.microedition.midlet.MIDletProxy.startApp(Unknown Source)
at com.sun.midp.midlet.Scheduler.schedule(Unknown Source)
at com.motorola.moja.jsr118.ApplicationManager.runLocalClass(Un known
Source)
at com.motorola.moja.jsr118.ApplicationManager.runApp(Unknown Source)
at com.motorola.moja.emulator.Emulator.<init>(Unknown Source)
at com.motorola.moja.emulator.Emulator.main(Unknown Source)

MTJ adds links to the stack trace on the console that points to the source
code lines. Looking at your stack trace I have identified that the error
is on a call to javax.microedition.lcdui.Form.append method. Part of the
method documentation says: "IllegalStateException - if the item is already
owned by a container." So I believe that the problem is that you are
adding an Item more than once. Adding break points before the append()
method call will clear your doubts.

Regards,

David Marques
Re: startApp threw an Exception [message #570288 is a reply to message #25342] Mon, 12 January 2009 17:28 Go to previous message
Eclipse User
Originally posted by: news.s237965939.online.de

Hello David,
see below...

David Marques wrote:
> Hello Hans,
>
> I don't clearly understand what you mean with "how can such exceptions
> be caught in the debugger?".

I mean that the debugger would suspend execution in that moment at that
source line where the exception takes place.

[Stack trace ...]

> MTJ adds links to the stack trace on the console that points to the
> source code lines. Looking at your stack trace I have identified that
> the error is on a call to javax.microedition.lcdui.Form.append method.
> Part of the method documentation says: "IllegalStateException - if the
> item is already owned by a container." So I believe that the problem is
> that you are adding an Item more than once. Adding break points before
> the append() method call will clear your doubts.

These are linenumbers indeed in the stack trace. Googeling around for
that problem i found in a forum someone claiming those were byte offsets
in the .class files, which would be rather useless. Obviousley wrong
information. But since these are really line numbers this kind of
post-mortem-debugging is useful for locating the error.

thanks again,
Hans
Re: startApp threw an Exception [message #570477 is a reply to message #25462] Tue, 13 January 2009 00:29 Go to previous message
Craig Setera is currently offline Craig Setera
Messages: 54
Registered: July 2009
Member
Hans,

A couple of comments below...

Hans-J. Ude wrote:
> Hello David,
> see below...
>
> David Marques wrote:
>> Hello Hans,
>>
>> I don't clearly understand what you mean with "how can such exceptions
>> be caught in the debugger?".
>
> I mean that the debugger would suspend execution in that moment at that
> source line where the exception takes place.
>

Unfortunately, while this is supported by the Eclipse debugger, it is
not generally supported by the JavaME emulators. The JavaME emulators
run what is referred to as a KVM (kilobyte virtual machine) that is
smaller than a full JavaSE virtual machine. There is a debugging proxy
that sits in front of the KVM to provide the standard JDWP debugger
protocol for Eclipse to debug the emulator. Unfortunately, somewhere in
the combination of the KVM and the debugger proxy, there are features
that are not implemented or supported. Thus, you can't do that. It is
also the reason that MTJ has some special requirements for debugger
settings. (It is also the reason I had to convince the Java debugger
gurus to accept an ugly patch that hacked the debugger for KVM
connections a few years ago <grin>)

> [Stack trace ...]
>
>> MTJ adds links to the stack trace on the console that points to the
>> source code lines. Looking at your stack trace I have identified that
>> the error is on a call to javax.microedition.lcdui.Form.append method.
>> Part of the method documentation says: "IllegalStateException - if the
>> item is already owned by a container." So I believe that the problem
>> is that you are adding an Item more than once. Adding break points
>> before the append() method call will clear your doubts.
>
> These are linenumbers indeed in the stack trace. Googeling around for
> that problem i found in a forum someone claiming those were byte offsets
> in the .class files, which would be rather useless. Obviousley wrong
> information. But since these are really line numbers this kind of
> post-mortem-debugging is useful for locating the error.
>
> thanks again,
> Hans

You are correct that those are byte code offsets. I believe we merged a
patch from another developer that should allow you to click on those
links and get to the correct line number. If that isn't working, there
may be a bug.

Craig
Previous Topic:Debugging a Midlet [caution MTJ noob inside]
Next Topic:MMAPI: Moto Q8 emulator fails
Goto Forum:
  


Current Time: Tue Oct 21 21:30:31 GMT 2014

Powered by FUDForum. Page generated in 0.02491 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software