harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Luht" <anton.l...@gmail.com>
Subject Re: [drlvm] crash handling
Date Fri, 28 Jul 2006 11:01:11 GMT
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 <gshimansky@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


Mime
View raw message