The following test case case leads to a compilation error in Rhino. In this
script alert is an user defined
function in the global object and it shows the value of the specified
parameter in a popup window. Save the script as a html file and run it under
Netscape and IE. The output via their JS engines is that alert(1)
executes but the execution of line fails as blks variable is undefined. The
Fix bug:
Rhino engine fails at compilation time itself and cannot excute the script.
It doesn't like the syntax of line.
Steven
/// **************** test case ************** ///
<script>
alert(1);
blks[ 10 << 2 ] |= true;
alert(2);
</script>
/// ********************** Error Message ************************** ////
evaluating script: null
java.lang.NullPointerException
at org.mozilla.javascript.Interpreter.generateICode(Compiled Code)
at org.mozilla.javascript.Interpreter.generateICode(Compiled Code)
at org.mozilla.javascript.Interpreter.generateICode(Compiled Code)
at org.mozilla.javascript.Interpreter.generateICode(Compiled Code)
at org.mozilla.javascript.Interpreter.generateICode(Compiled Code)
at org.mozilla.javascript.Interpreter.generateICodeFromTree(Compiled Code)
at
org.mozilla.javascript.Interpreter.generateScriptICode(Interpreter.java)
at org.mozilla.javascript.Interpreter.compile(Interpreter.java)
at org.mozilla.javascript.Context.compile(Context.java)
at org.mozilla.javascript.Context.compile(Context.java)
large addition to the jsd_xpc component allows arbitrary filtering of debug hooks by url pattern, line range, and global object. also adds ability to begin instrumenting jsscripts at app startup.
I must admit this is very subtitle, but still...
Here are the lines from
public void defineProperty(String propertyName, Object delegateTo,
Method getter, Method setter, int attributes)
GetterSlot slot = (GetterSlot)getSlotToSet(propertyName,
propertyName.hashCode(),
true);
slot.delegateTo = delegateTo;
slot.getter = getter;
slot.setter = setter;
slot.setterReturnsValue = setter != null && setter.getReturnType() != Void.TYPE;
slot.value = null;
slot.attributes = (short) attributes;
slot.flags = (byte)flags;
Now suppose that after the new slot is added, another thread is accessing it. Then it would see not yet ready slot with all nasty consequences! For example, SMP computer can re-arrange writes so the new value of slot.flags would be visible before slot.getter then another thread would generate null pointer exception.
race2_fix.diff fixes that by using the explicit Slot argument to addSlot instead of boolean flag so the new slot can be fully initialized and then inserted under synchronization to the table. I also call addSlot directly because it is supposed to be used with not-yet existed properties and split addSlot to addSlot and addSlotImpl so in case of table growth there is no need to re-enter already synchronized monitor.
This changes also allows to explicitly throw RuntimeException if defineProperty is called for the property that is already exists instead of either throwing cast exception in "GetterSlot slot = (GetterSlot)getSlotToSet(propertyName," or worth yet re-initializing already existed slot.
Regards, Igor
dbaron%fas.harvard.edu
brendan%mozilla.org
jband%netscape.com
rginda%netscape.com
seawood%netscape.com
peterv%netscape.com
pschwartau%netscape.com
dbradley%netscape.com
pete%alphanumerica.com
nboyd%atg.com
mike+mozilla%meer.net
alecf%netscape.com
jst%netscape.com
jaggernaut%netscape.com