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.
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...
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?
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
> 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
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.
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,
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.
get used to it.
Oracle do the same.
so does novell.
steve
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...
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
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.