You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Anton Luht <an...@gmail.com> on 2006/07/27 18:47:45 UTC
[drlvm] crash handling
Hello,
I've been trying to nail down a small problem - new
java.util.zip.Deflater().setDictionary(new byte[] {}) throws
ArrayIndexOutOfBoundsException in Harmony and doesn't throw in RI.
Trying to find a code that causes this problem I've modified native
code and after one of modifications VM crashed, but not with usual
stacktrace but with popup window (I did it on Windows) that offered to
debug my application.
I fully understand that it was my fault, etc, but I believe that
Harmony code is not 100% error-free and such errors in native code may
happen. Maybe it's worth to catch such errors and wrap them into
regular Exceptions or at least print stacktrace to the console.
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] crash handling
Posted by Gregory Shimansky <gs...@gmail.com>.
2006/7/28, Anton Luht <an...@gmail.com>:
>
> Gregory,
>
> Thanks for the pointing at this option - maybe it's worth to publish
> undocumented properties and other switches, for example, in Wiki?
>
> With this option VM printed before death:
>
> Windows reported exception: ACCESS_VIOLATION
> Registers:
> EAX: 0x00000000, EBX: 0x00000000, ECX: 0x05d4f860, EDX=0x00060002
> ESI: 0x00166040, EDI: 0x052e8190, ESP: 0x05d4f824, EBP=0x00000000
> EIP: 0x053124ef
> CallStack:
> Java_java_util_zip_Deflater_setDictionaryImpl (File:
> .............\modules\archive\src\main\native\archive\shared\deflater.c
> Line: 46 )
> m2n_pop_local_handles (File: ..............\vm\port\src\lil\ia32\pi
> m\m2n_ia32.cpp Line: 229 )
> No name (File: ?? Line: ?? ) No name (File: ?? Line: ?? )
>
> I think it'd be better for a developer to see Java stacktrace as well.
> Am I asking for something impossible?:)
Sure I've written that crash stack dump needs improvement. On Linux I think
it is able to print symbols only from libvmcore.so, so you won't see Java
native functions in the dump as well.
It just serves a different purpose, if you need to debug the native code
windows on the fly debugging is more useful than stack dump.
On 7/27/06, Gregory Shimansky <gs...@gmail.com> wrote:
> > On Thursday 27 July 2006 20:47 Anton Luht wrote:
> > > Hello,
> > >
> > > I've been trying to nail down a small problem - new
> > > java.util.zip.Deflater().setDictionary(new byte[] {}) throws
> > > ArrayIndexOutOfBoundsException in Harmony and doesn't throw in RI.
> > > Trying to find a code that causes this problem I've modified native
> > > code and after one of modifications VM crashed, but not with usual
> > > stacktrace but with popup window (I did it on Windows) that offered to
> > > debug my application.
> > >
> > > I fully understand that it was my fault, etc, but I believe that
> > > Harmony code is not 100% error-free and such errors in native code may
> > > happen. Maybe it's worth to catch such errors and wrap them into
> > > regular Exceptions or at least print stacktrace to the console.
> >
> > There is an undocumented drlvm property vm.assert_dialog which controls
> this
> > crash popup window on windows. By default this property is true, and you
> > indeed get a debug window when VM or Java native code crash. It is very
> > convenient for debugging because it allows attaching a debugger (if it
> is
> > installed in your system) right at the crash or failed assert point. To
> show
> > the stack trace instead you can specify -Dvm.assert_dialog=false to run
> the
> > program, it should try to dump some stack though I don't think it works
> for
> > native Java code at the moment. I think crash handler needs improvement
> in
> > this regard.
> >
> > Whether or not the default of vm.assert_dialog should be true of false
> is the
> > same argument about whether debug or release mode should be the default.
> I
> > think it was agreed that debug should be default so far to make it
> convenient
> > for developers.
> >
> > For you case I think it is preferable to crash window enabled since that
> is
> > what you want - debug the native code at crash point. To do it you
> should
> > just compile that native code with debug information and copy pdb file
> to
> > java executable directory.
> >
> > --
> > Gregory Shimansky, Intel Middleware Products Division
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
> --
> Regards,
> Anton Luht,
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm] crash handling
Posted by Alexey Varlamov <al...@gmail.com>.
2006/7/28, Anton Luht <an...@gmail.com>:
> Gregory,
>
> Thanks for the pointing at this option - maybe it's worth to publish
> undocumented properties and other switches, for example, in Wiki?
>
Anton,
java -X
will print a(n almost) complete list of supported properties. A
document placed elsewhere would have good chances to become outdated
soon.
[snip]
--
Alexey
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] crash handling
Posted by Anton Luht <an...@gmail.com>.
Gregory,
Thanks for the pointing at this option - maybe it's worth to publish
undocumented properties and other switches, for example, in Wiki?
With this option VM printed before death:
Windows reported exception: ACCESS_VIOLATION
Registers:
EAX: 0x00000000, EBX: 0x00000000, ECX: 0x05d4f860, EDX=0x00060002
ESI: 0x00166040, EDI: 0x052e8190, ESP: 0x05d4f824, EBP=0x00000000
EIP: 0x053124ef
CallStack:
Java_java_util_zip_Deflater_setDictionaryImpl (File:
.............\modules\archive\src\main\native\archive\shared\deflater.c
Line: 46 )
m2n_pop_local_handles (File: ..............\vm\port\src\lil\ia32\pi
m\m2n_ia32.cpp Line: 229 )
No name (File: ?? Line: ?? ) No name (File: ?? Line: ?? )
I think it'd be better for a developer to see Java stacktrace as well.
Am I asking for something impossible?:)
On 7/27/06, Gregory Shimansky <gs...@gmail.com> wrote:
> On Thursday 27 July 2006 20:47 Anton Luht wrote:
> > Hello,
> >
> > I've been trying to nail down a small problem - new
> > java.util.zip.Deflater().setDictionary(new byte[] {}) throws
> > ArrayIndexOutOfBoundsException in Harmony and doesn't throw in RI.
> > Trying to find a code that causes this problem I've modified native
> > code and after one of modifications VM crashed, but not with usual
> > stacktrace but with popup window (I did it on Windows) that offered to
> > debug my application.
> >
> > I fully understand that it was my fault, etc, but I believe that
> > Harmony code is not 100% error-free and such errors in native code may
> > happen. Maybe it's worth to catch such errors and wrap them into
> > regular Exceptions or at least print stacktrace to the console.
>
> There is an undocumented drlvm property vm.assert_dialog which controls this
> crash popup window on windows. By default this property is true, and you
> indeed get a debug window when VM or Java native code crash. It is very
> convenient for debugging because it allows attaching a debugger (if it is
> installed in your system) right at the crash or failed assert point. To show
> the stack trace instead you can specify -Dvm.assert_dialog=false to run the
> program, it should try to dump some stack though I don't think it works for
> native Java code at the moment. I think crash handler needs improvement in
> this regard.
>
> Whether or not the default of vm.assert_dialog should be true of false is the
> same argument about whether debug or release mode should be the default. I
> think it was agreed that debug should be default so far to make it convenient
> for developers.
>
> For you case I think it is preferable to crash window enabled since that is
> what you want - debug the native code at crash point. To do it you should
> just compile that native code with debug information and copy pdb file to
> java executable directory.
>
> --
> Gregory Shimansky, Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [drlvm] crash handling
Posted by Gregory Shimansky <gs...@gmail.com>.
On Thursday 27 July 2006 20:47 Anton Luht wrote:
> Hello,
>
> I've been trying to nail down a small problem - new
> java.util.zip.Deflater().setDictionary(new byte[] {}) throws
> ArrayIndexOutOfBoundsException in Harmony and doesn't throw in RI.
> Trying to find a code that causes this problem I've modified native
> code and after one of modifications VM crashed, but not with usual
> stacktrace but with popup window (I did it on Windows) that offered to
> debug my application.
>
> I fully understand that it was my fault, etc, but I believe that
> Harmony code is not 100% error-free and such errors in native code may
> happen. Maybe it's worth to catch such errors and wrap them into
> regular Exceptions or at least print stacktrace to the console.
There is an undocumented drlvm property vm.assert_dialog which controls this
crash popup window on windows. By default this property is true, and you
indeed get a debug window when VM or Java native code crash. It is very
convenient for debugging because it allows attaching a debugger (if it is
installed in your system) right at the crash or failed assert point. To show
the stack trace instead you can specify -Dvm.assert_dialog=false to run the
program, it should try to dump some stack though I don't think it works for
native Java code at the moment. I think crash handler needs improvement in
this regard.
Whether or not the default of vm.assert_dialog should be true of false is the
same argument about whether debug or release mode should be the default. I
think it was agreed that debug should be default so far to make it convenient
for developers.
For you case I think it is preferable to crash window enabled since that is
what you want - debug the native code at crash point. To do it you should
just compile that native code with debug information and copy pdb file to
java executable directory.
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org