How do you report a JIT crash bug?
Mickey Segal
file on my desktop. The log begins:
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7c9010f3, pid=1312,
tid=3304
Is there something one can do with these files? This crash occurred with a
very large Java applet and it is unlikely that Sun will want to look through
tens of thousands of lines of code.
Andy Flowers
http://developer.java.sun.com/servlet/SessionServlet?url=/developer/bugParade/index.jshtml
You will probably have to sign up, unless you already have an account, but
it's free.
"Mickey Segal" <ign...@example.com> wrote in message
news:fJidnR-QV6G...@rcn.net...
Mickey Segal
news:dNcid.446$c37...@newsfe1-gui.ntli.net...
> Got take a look at
> http://developer.java.sun.com/servlet/SessionServlet?url=/developer/bugParade/index.jshtml
My question is not about how to report a generic bug; I've reported several
Sun bugs and many were accepted and fixed within weeks. My question is how
one can get Sun to take seriously a bug report for which you do not have a
reductionistic example, but merely have crash reports and a huge applet.
Should one just submit the JIT crash reports and say it crashed? Do the
crash reports reveal information that discloses data or program code?
Thomas Weidenfeller
> My question is not about how to report a generic bug; I've reported several
> Sun bugs and many were accepted and fixed within weeks. My question is how
> one can get Sun to take seriously a bug report
Pay them. No joke. Sun offers professional services, where experts even
come down to your site and look at the stuff.
I never did this for Java, but I went through this a few times, e.g.
when hunting nasty bugs in their C/C++ compiler.
/Thomas
Chris Uppal
> Pay them. No joke. Sun offers professional services, where experts even
> come down to your site and look at the stuff.
>
> I never did this for Java, but I went through this a few times, e.g.
> when hunting nasty bugs in their C/C++ compiler.
/You/ pay /them/ to look for bugs in /their/ software ? Wow !
Now that's the business to be in...
-- chris
Michael Borgwardt
That's how most software development works. Note that the emphasis is
more like: /You/ pay them to look for bugs in their software that
/you/ need fixed.
Mickey Segal
news:VsGdnZHmXPz...@nildram.net...
> /You/ pay /them/ to look for bugs in /their/ software ? Wow !
>
> Now that's the business to be in...
The part of our software with the JIT crashes is only needed by 5% of our
users, those who contribute information to our database, so we can get them
to use the Microsoft JVM or use a Macintosh. Hopefully someone else will
notice the problem in a simpler context and report it, or be so dependent on
Sun than they are willing to pay to fix Sun bugs.
Mickey Segal
can't be released so I posted two at www.segal.org/java/sun_jit/. If anyone
has any clues about how to read such tea leaves in a way that would help Sun
fix the bug or help me work around it I'd be interested. A lot of Java
methods are mentioned but it doesn't seem as easy to interpret as a typical
Exception trace in a Java Console.
Sudsy
Mickey,
It looks like a call to Component.removeAll is invoking the underlying
Component.removeNotify, which is supposed to disconnect from the native
peer. The code is dying in a native method in NTDLL.DLL.
Now this is just a wild shot in the dark but I wouldn't be surprised
to see something like this if you were trying to remove the container
twice; once in the MouseReleased method and again in the calling method.
Without seeing the code it's impossible to guess further.
Perhaps you've invoked addMouseListener on a Dialog?
--
Java/J2EE/JSP/Struts/Tiles/C/UNIX consulting and remote development.
steve
(in article <VsGdnZHmXPz...@nildram.net>):
get used to it.
Oracle do the same.
so does novell.
steve
Mickey Segal
> It looks like a call to Component.removeAll is invoking the underlying
> Component.removeNotify, which is supposed to disconnect from the native
> peer. The code is dying in a native method in NTDLL.DLL.
> Now this is just a wild shot in the dark but I wouldn't be surprised
> to see something like this if you were trying to remove the container
> twice; once in the MouseReleased method and again in the calling method.
> Without seeing the code it's impossible to guess further.
> Perhaps you've invoked addMouseListener on a Dialog?
The crashes occur at a point in which a Panel is removed and another Panel
is created and added in its place. The Panel is not removed twice. This
works fine 99% of the time with the Sun JVM and 100% of the time with the
Microsoft JVM. I don't think any relevant code has changed in a long time;
I only noticed the problem as of JRE 1.5.0.
Sudsy
<snip>
> The crashes occur at a point in which a Panel is removed and another Panel
> is created and added in its place. The Panel is not removed twice. This
> works fine 99% of the time with the Sun JVM and 100% of the time with the
> Microsoft JVM. I don't think any relevant code has changed in a long time;
> I only noticed the problem as of JRE 1.5.0.
Any chance of posting an abbreviated example? Just the relevant code where
you're performing the Panel replacement...
Thomas Weidenfeller
> /You/ pay /them/ to look for bugs in /their/ software ? Wow !
>
> Now that's the business to be in...
Welcome to the real world. But from other postings of the OP it looks as
if the problem isn't as important to him as he originally presented it.
Which means, the alternative of just sitting there and waiting seems to
be ok, too.
/Thomas
Mickey Segal
news:418F13BD...@hotmail.com...
> Any chance of posting an abbreviated example? Just the relevant code where
> you're performing the Panel replacement...
It is difficult to do this in a way that is anywhere near complete since the
applet has 160 classes and about 30,000 lines of code. But the code with
the removeAll method is:
page = instantiateClass(pageCode);
page.resetValuesForPage();
removeAll();
page.reLayoutPage();
Page.constrain(this, page, 0, 0, 1, 1, GridBagConstraints.NORTH, 0, 0, 0, 0,
GridBagConstraints.BOTH, 1, 1);
validate(); // calls setBounds and makes TextFields visible for setText to
call textValueChanged
page.resetFocusForPage(); // after components are visible
invalidate();
validate(); // makes new components get their proper space
The one kludgy part of the code is two calls to validate, as a workaround
for a Sun Java bug:
www.segal.org/java/text_events/
in which one can't write to a TextField until it is validated if one is
expecting Pen input. On my "to do" list is to find a more elegant
workaround because it adds a lot of flicker in the Sun JVM, though not
elsewhere. If two calls to validate may be causing crashes 1% of the time I
might give this a higher priority.