Prev: Followup to "Serious concurrency problems on fast systems"
Next: how to print jtables in a print.book
From: FutureScalper on 2 Jul 2010 15:05

I conclude after much working with this issue that the Security
Warning is somehow erroneously triggered, even though it is explicitly
disabled.

I believe this is a BUG but someone can enlighten me, please? Note
easily reproducible because things work for perhaps several hours
before problems occur. This app needs to run unattended 24 x 7.

If I can't get rid of this, I'll have to back down to Java 6 Update 17
and stay there until it's resolved.

I can run for hours, and then suddenly I get the Security Warning for
mixed code. Everything is signed, and the system is configured as
follows, with Web Start as the deployer.

The app does not contain any custom classloaders, nor do anything
except just run standalone.

In Windows/Sun/Java/Deployment (which is definitely being used)

deploiyment.config contains:
deployment.system.config=file:/C:/windows/Sun/Java/Deployment/
deployment.properties
deployment.system.config.mandatory=true

deployment.properties contains:
deployment.security.mixcode=DISABLE

C:\Windows\SysWOW64>java -server -version
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode)

The following exception is false. Signer information is the same in
all packages, as far as I know. (I signed everything and control the
deployment.)

Exception in thread "AWT-EventQueue-0" java.lang.SecurityException:
class "com.twc.trader.SupportResistanceDialog$1"'s signer information
does not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(Unknown Source)
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at com.twc.trader.SupportResistanceDialog.<init>(Unknown Source)
at com.twc.trader.Core.getSupportResistanceDialog(Unknown Source)
at com.twc.trader.TickAnalyzer.update(Unknown Source)
at com.twc.trader.PriceMicroDetailWindow.notifyObservers(Unknown
Source)
at com.twc.trader.PriceMicroDetailWindow$1.chartMouseClicked(Unknown
Source)
at org.jfree.chart.ChartPanel.mouseClicked(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown
Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown
Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
From: FutureScalper on 2 Jul 2010 15:14
On Jul 2, 3:05 pm, FutureScalper <futurescal...(a)gmail.com> wrote:
> I conclude after much working with this issue that the Security
> Warning is somehow erroneously triggered, even though it is explicitly
> disabled.
>
> I believe this is a BUG but someone can enlighten me, please?  Note
> easily reproducible because things work for perhaps several hours
> before problems occur.  This app needs to run unattended 24 x 7.
>
> If I can't get rid of this, I'll have to back down to Java 6 Update 17
> and stay there until it's resolved.
>
> I can run for hours, and then suddenly I get the Security Warning for
> mixed code.  Everything is signed, and the system is configured as
> follows, with Web Start as the deployer.
>
> The app does not contain any custom classloaders, nor do anything
> except just run standalone.
>
> In Windows/Sun/Java/Deployment (which is definitely being used)
>
> deploiyment.config contains:
> deployment.system.config=file:/C:/windows/Sun/Java/Deployment/
> deployment.properties
> deployment.system.config.mandatory=true
>
> deployment.properties contains:
> deployment.security.mixcode=DISABLE
>
> C:\Windows\SysWOW64>java -server -version
> java version "1.6.0_20"
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
> Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode)
>
> The following exception is false.  Signer information is the same in
> all packages, as far as I know.  (I signed everything and control the
> deployment.)
>
> Exception in thread "AWT-EventQueue-0" java.lang.SecurityException:
> class "com.twc.trader.SupportResistanceDialog$1"'s signer information
> does not match signer information of other classes in the same package
>         at java.lang.ClassLoader.checkCerts(Unknown Source)
>         at java.lang.ClassLoader.preDefineClass(Unknown Source)
>         at java.lang.ClassLoader.defineClassCond(Unknown Source)
>         at java.lang.ClassLoader.defineClass(Unknown Source)
>         at java.security.SecureClassLoader.defineClass(Unknown Source)
>         at java.net.URLClassLoader.defineClass(Unknown Source)
>         at java.net.URLClassLoader.access$000(Unknown Source)
>         at java.net.URLClassLoader$1.run(Unknown Source)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(Unknown Source)
>         at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
>         at java.lang.ClassLoader.loadClass(Unknown Source)
>         at java.lang.ClassLoader.loadClass(Unknown Source)
>         at com.twc.trader.SupportResistanceDialog.<init>(Unknown Source)
>         at com.twc.trader.Core.getSupportResistanceDialog(Unknown Source)
>         at com.twc.trader.TickAnalyzer.update(Unknown Source)
>         at com.twc.trader.PriceMicroDetailWindow.notifyObservers(Unknown
> Source)
>         at com.twc.trader.PriceMicroDetailWindow$1.chartMouseClicked(Unknown
> Source)
>         at org.jfree.chart.ChartPanel.mouseClicked(Unknown Source)
>         at java.awt.Component.processMouseEvent(Unknown Source)
>         at javax.swing.JComponent.processMouseEvent(Unknown Source)
>         at java.awt.Component.processEvent(Unknown Source)
>         at java.awt.Container.processEvent(Unknown Source)
>         at java.awt.Component.dispatchEventImpl(Unknown Source)
>         at java.awt.Container.dispatchEventImpl(Unknown Source)
>         at java.awt.Component.dispatchEvent(Unknown Source)
>         at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
>         at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
>         at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
>         at java.awt.Container.dispatchEventImpl(Unknown Source)
>         at java.awt.Window.dispatchEventImpl(Unknown Source)
>         at java.awt.Component.dispatchEvent(Unknown Source)
>         at java.awt.EventQueue.dispatchEvent(Unknown Source)
>         at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown
> Source)
>         at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
>         at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown
> Source)
>         at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
>         at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
>         at java.awt.EventDispatchThread.run(Unknown Source)

OK, I see a couple of typos in my post, but I can assure you that
deployment.config is correct, is being used, and deployment.properties
is mandatory, and my understanding is that the property will DISABLE
Security Warning checking.

But, several instances of my app fail at different random points,
after many hours of running, and there appears to be no pattern except
that the Security Warning behavior reappears for no apparent reason
when the GUI tries some action. Apparently random.
From: Eric Sosman on 2 Jul 2010 15:42
On 7/2/2010 3:05 PM, FutureScalper wrote:
>[...]
> I believe this is a BUG but someone can enlighten me, please? Note
> easily reproducible because things work for perhaps several hours
> before problems occur. This app needs to run unattended 24 x 7.
>[...]
> I can run for hours, and then suddenly I get the Security Warning for
> mixed code. Everything is signed, and the system is configured as
> follows, with Web Start as the deployer.
>
> The app does not contain any custom classloaders, nor do anything
> except just run standalone.

This seems odd. You say it runs "standalone" and "unattended,"
yet the exception occurs on thread AWT-EventQueue-0, which suggests
that there's a GUI somewhere. The stack trace seems to show that a
mouse click is being processed by Swing components -- if the app is
standalone and unattended, who's clicking mouse buttons?

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.

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.

Good luck!

--
Eric Sosman
esosman(a)ieee-dot-org.invalid
From: FutureScalper on 3 Jul 2010 10:54
On Jul 2, 3:42 pm, Eric Sosman <esos...(a)ieee-dot-org.invalid> wrote:
> On 7/2/2010 3:05 PM, FutureScalper wrote:
>
> >[...]
> > I believe this is a BUG but someone can enlighten me, please?  Note
> > easily reproducible because things work for perhaps several hours
> > before problems occur.  This app needs to run unattended 24 x 7.
> >[...]
> > I can run for hours, and then suddenly I get the Security Warning for
> > mixed code.  Everything is signed, and the system is configured as
> > follows, with Web Start as the deployer.
>
> > The app does not contain any custom classloaders, nor do anything
> > except just run standalone.
>
>      This seems odd.  You say it runs "standalone" and "unattended,"
> yet the exception occurs on thread AWT-EventQueue-0, which suggests
> that there's a GUI somewhere.  The stack trace seems to show that a
> mouse click is being processed by Swing components -- if the app is
> standalone and unattended, who's clicking mouse buttons?
>
>      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.
>
>      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.
>
>      Good luck!
>
> --
> Eric Sosman
> esos...(a)ieee-dot-org.invalid

Okay, thanks for your response. Take it easy, yes it's a GUI driven
application but it does run unattended usually overnight, and runs
24x7 whether operator is present or not. Now, I admit I've only seen
the problem when clicking a button, or when an action listener wants
to do something, like put up that dialog. That's true.

Perhaps I don't understand the concept of "signing". I sign the jars,
and is that not sufficient? 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.

I am not aware of any network-loaded classes, and that's a great
suggestion. The application does do RMI amongst copies of itself but
I don't believe that's the problem. The intent is that it can run
standalone, without an internet connection, on an isolated machine as
well as during live online trading, of course.

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...

Here's the jnlp used to run the thing, which resides on a webserver,
and it uses 5 locally cached jars, plus the installed JRE of course,
which is not the Client VM, but the Sun Java Server VM for high
performance.

Is there something in this jnlp which would trigger class loading over
the network? That's a subtlety I hadn't thought of....

<?xml version="1.0" encoding="UTF-8" ?>
<jnlp spec="1.0+" codebase="http://FutureScalper.com/[location
removed]/serverbeta_ta" href="FutureScalperServerBeta_ta.jnlp">

<information>
<title>FutureScalper Server TA BETA</title>
<vendor>FutureScalper.com</vendor>
<description>FutureScalper Server TA BETA</description>
<homepage href="http://FutureScalper.com/[location removed]/
serverbeta_ta" />
<offline-allowed />
</information>

<security>
<all-permissions />
</security>

<resources>
<j2se version="1.6.0+" java-vm-args=" -server -
-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1TimeSliceMS=40 -
-XX:+G1ParallelRSetUpdatingEnabled -XX:+G1ParallelRSetScanningEnabled
-
-XX:GCPauseIntervalMillis=250 -
-XX:ThreadStackSize=128 -XX:CompileThreshold=20 -
-XX:CICompilerCount=4 -XX:+UseBiasedLocking -
-XX:+AggressiveHeap -XX:+ForceTimeHighResolution -
-XX:+RelaxAccessControlCheck -XX:-TieredCompilation -
-XX:MaxInlineSize=256000 -Xverify:none -XX:FreqInlineSize=256000 -XX:-
DontCompileHugeMethods -
-XX:+UseFastAccessorMethods -Xss128k -Xms370m -Xmx370m -Xbatch -
Xnoclassgc -
-Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel
--Dswing.metalTheme=steel -
-Ddeployment.security.mixcode=DISABLE -
-Duser.timezone=America/New_York -Duser.language=en -Duser.region=US /
>

<property name="sun.java2d.noddraw" value="true" />
<property name="sun.java2d.d3d" value="false" />
<property name="java.rmi.server.hostname" value="127.0.0.1" />
<property name="deployment.security.mixcode" value="DISABLE" />

<jar href="sFutureScalper.jar" download="eager" main="true" />
<jar href="sFutureScalperChart.jar" download="eager" main="false" /
>
<jar href="sFutureScalperSounds.jar" download="eager" main="false" /
>
<jar href="sFutureScalperContracts.jar" download="eager"
main="false" />
<jar href="sFutureScalperAuth.jar" download="eager" main="false" /
>
</resources>

<application-desc main-class="com.twc.trader.FutureScalper">
<argument>command-line-argument</argument>
</application-desc>

</jnlp>
From: Eric Sosman on 3 Jul 2010 16:33
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
esosman(a)ieee-dot-org.invalid
 |  Next  |  Last
Pages: 1 2 3
Prev: Followup to "Serious concurrency problems on fast systems"
Next: how to print jtables in a print.book