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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
