Prev: Followup to "Serious concurrency problems on fast systems"
Next: how to print jtables in a print.book
From: FutureScalper on 4 Jul 2010 08:54
On Jul 3, 4:33 pm, Eric Sosman <esos...(a)ieee-dot-org.invalid> wrote:
> On 7/3/2010 10:54 AM, FutureScalper wrote:
>
>
>
>
>
> > On Jul 2, 3:42 pm, Eric Sosman<esos...(a)ieee-dot-org.invalid>  wrote:
> >> [...]
> >>       Also, the app doesn't merely "run for hours" and suddenly hit
> >> trouble while doing the same things it's been doing all along.  The
> >> JVM is trying to load the com.twc.trader.SupportResistanceDialog$1
> >> class, which it wouldn't be doing if it had been using that class
> >> "for hours" and had thus loaded it earlier; this is the first time
> >> com.twc.trader.SupportResistanceDialog$1 has been called for.  (It's
> >> possible for a class to be loaded, discarded, and re-loaded, but
> >> since you say you're doing no ClassLoader trickery that seems fairly
> >> unlikely.)  I think you should focus your attention on the signing of
> >> this seldom-used nested class, and see if that turns up anything of
> >> interest.  At the very least, knowing the particular class that's
> >> involved may help you reproduce the problem with less waiting around.
> > [...] There are plenty of times the app pulls
> > up this particular dialog just fine.  And other times it does not.
> > This inconsistency is the issue here.  Also, I've seen the Security
> > Warning on other action listeners as well.  Since the problem is
> > intermittent and difficult to reproduce, I can't say whether the
> > particular function was used in the past or not.
>
>      Function, schmunction: The stack trace you provided shows that
> the trouble is in loading com.twc.trader.SupportResistanceDialog$1.
> The JVM wouldn't be loading the class if it had already been loaded
> previously (unless you're doing something odd with ClassLoaders, which
> you say you're not), so this is the first time the class has been used.
> Find out what the class is (from its name, it looks like a nested class
> within com.twc.trader.SupportResistanceDialog), find out what action
> causes it to be loaded, and you'll be well on the way to understanding
> the chain of events that leads to the failure.  That's not a solution
> in and of itself, but you'll at least have a way to provoke failures
> "more reliably."
>
> >>       I don't know whether it makes a difference, but the troublesome
> >> class is being loaded from the network, not from a local source.  Maybe
> >> you've got a mismatched mixture of old, cached classes with fresh
> >> somewhere-over-the-network classes?  It might be helpful to turn on the
> >> JVM's trace of class-loading activity, and see if anything's weird.
>
> > I am not aware of any network-loaded classes, [...]
>
> > I will see whether for some weird reason attempts are being made to
> > load classes over the network.  I'll investigate how you came to this
> > conclusion and maybe there is something weird going on here...
>
>      See those java.net.URLClassLoader methods in the stack trace?
>
>      Let me narrow it down a little more for you: The class gets loaded
> while you're in com.twc.trader.SupportResistanceDialog.<init>, that is,
> while you're constructing an instance of SupportResistanceDialog.  I
> can't tell how many constructors this class has nor which of them is
> running, but at least one of them uses the nested class and somebody
> tries to load the nested class from the network.
>
> --
> Eric Sosman
> esos...(a)ieee-dot-org.invalid

Eric, there is NOTHING which should provoke classes being loaded "from
the network".

All JARs are local, all loads in this case are "ordinary"
instantiations.

Just because "...URL..." is in the name of the method doesn't mean the
"network" is involved.

ANYWAY, what part of "deployment.security.mixcode=DISABLE" does the
Java runtime NOT understand ????

To me, it doesn't go any further than that. If deployment.config is
correctly set, and mandates deployment.properties, and it contains
"deployment.security.mixcode=DISABLE" then it should be GAME OVER for
mixed code Security Warnings.

What more is there to this issue? I should NOT be receiving the mixed
code Security Warning.

Under what circumstances should this ever happen, given the
specifications for the property "deployment.security.mixcode=DISABLE".

Please explain it to me; and in the meantime, I have to freeze at Sun
Java 6 Update 17 until what I strongly suspect is a bug, is resolved.

The class in question is loaded 99.9% of the time without issue. I
believe the VM "reverts" erroneously to mixed code checking at
runtime, as I've had issues with other classes being loaded, also as a
result of a GUI activity. Again, I'm just asking why the
inconsistency? If it's NOT entitled to be loaded, then it should
NEVER load, or am I being naive here?

I am very appreciative of your replies.

From: Eric Sosman on 4 Jul 2010 11:04
On 7/4/2010 8:54 AM, FutureScalper wrote:
> [...]
> Just because "...URL..." is in the name of the method doesn't mean the
> "network" is involved.

Sorry; my mistake. I keep forgetting that "URL" encompasses
a lot more things than network protocols.

> The class in question is loaded 99.9% of the time without issue.

Why do you believe so? Why do you believe this class, unlike
practically all other classes, is loaded more than once? Have you
traced the JVM's loading of classes? Have you even traced the
loading of this one particular class, perhaps by putting a logging
call in its static initialization code? Have you even determined
what the class *is* -- yes, we know its synthetic name, but have
you figured out which bit of source code it corresponds to?

You keep rending your garments and tearing your hair about the
injustice of a SecurityException, but I've seen nothing to indicate
you're doing anything but the tearing and rending -- except, maybe,
the "99.9%" figure, but I suspect you just plucked that one from the
air. How did you measure it? What experiments have you tried?

--
Eric Sosman
esosman(a)ieee-dot-org.invalid
From: FutureScalper on 4 Jul 2010 15:05
On Jul 4, 11:04 am, Eric Sosman <esos...(a)ieee-dot-org.invalid> wrote:
> On 7/4/2010 8:54 AM, FutureScalper wrote:
>
> > [...]
> > Just because "...URL..." is in the name of the method doesn't mean the
> > "network" is involved.
>
>      Sorry; my mistake.  I keep forgetting that "URL" encompasses
> a lot more things than network protocols.
>
> > The class in question is loaded 99.9% of the time without issue.
>
>      Why do you believe so?  Why do you believe this class, unlike
> practically all other classes, is loaded more than once?  Have you
> traced the JVM's loading of classes?  Have you even traced the
> loading of this one particular class, perhaps by putting a logging
> call in its static initialization code?  Have you even determined
> what the class *is* -- yes, we know its synthetic name, but have
> you figured out which bit of source code it corresponds to?
>
>      You keep rending your garments and tearing your hair about the
> injustice of a SecurityException, but I've seen nothing to indicate
> you're doing anything but the tearing and rending -- except, maybe,
> the "99.9%" figure, but I suspect you just plucked that one from the
> air.  How did you measure it?  What experiments have you tried?
>
> --
> Eric Sosman
> esos...(a)ieee-dot-org.invalid

You've really got an attitude. Look, the class is MY code, it's an
ordinary JDialog and it's loaded only once. It loads fine, and I
repeat 99.9% of the time. I don't care of that initial load is first
in the session or a couple of hours later.

The only point here is that it should NEVER load if it's in violation
of the mixed code restriction, not sometimes.

And the mixed code restriction is switched off. Why doesn't that
impress you?

Never mind whether I've traced class loading... The point is that the
Security Warning intermittent issue is probably a BUG and I submitted
a bug report to Sun/Oracle on this.

From: Lew on 4 Jul 2010 15:19
FutureScalper wrote:
>> --
>> Eric Sosman
>> esos...(a)ieee-dot-org.invalid

Don't quote sigs.

> You've really got an attitude. Look, the class is MY code, it's an

He's got the attitude called "telling the truth".

The evidence strongly supports what Eric told you. The person disregarding
that evidence and resorting to ad hominem remarks is the one with the attitude.

> ordinary JDialog and it's loaded only once. It loads fine, and I
> repeat 99.9% of the time. I don't care of that initial load is first
> in the session or a couple of hours later.

But the stack trace shows that the error occurs during the load of the nested
class to which Eric pointed you, all your shouting notwithstanding.

> The only point here is that it should NEVER load if it's in violation
> of the mixed code restriction, not sometimes.
>
> And the mixed code restriction is switched off. Why doesn't that
> impress you?

Probably because the evidence favors what he said, not what you said.

> Never mind whether I've traced class loading... The point is that the

Never mind tracking down the real reason for the problem ...

> Security Warning intermittent issue is probably a BUG and I submitted
> a bug report to Sun/Oracle on this.

Oh, it's a "BUG" all right, just not in Sun's code.

--
Lew
From: Eric Sosman on 4 Jul 2010 15:19
On 7/4/2010 3:05 PM, FutureScalper wrote:
>
> You've really got an attitude.

Yes, I've got an attitude. My attitude is that your shirty
back-sass justifies me in tripling my fees for trying to help.

> Look, the class is MY code, it's an
> ordinary JDialog and it's loaded only once. It loads fine, and I
> repeat 99.9% of the time.

So you've actually recorded at least a thousand successful
class loadings with no more than one failure? R-i-i-g-h-t.

> Never mind whether I've traced class loading...

I think you have not, and that you're just sulking and making
excuses (and making up numbers). Listen, O Victim, it may in fact
be true that you have encountered a bug. But if you want justice
you need to do more than lie around complaining about it: You've
got to make a case, gather some evidence, investigate, do something
other than sit there in a tear-soaked passive wretchedness. And
you certainly need to stop abusing the passers-by who offer alms.

--
Eric Sosman
esosman(a)ieee-dot-org.invalid
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Followup to "Serious concurrency problems on fast systems"
Next: how to print jtables in a print.book