2006/7/28, Anton Luht <[EMAIL PROTECTED]>:
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 <[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]
--
Gregory Shimansky, Intel Middleware Products Division
