Subject:
rhino bug(s)
Date:
Mon, 30 Apr 2001 23:07:00 -0700
From:
Mike Dixon <MDixon@placeware.com>
To:
nboyd@atg.com
hi. i'm a happy rhino user, and just stumbled across what looks like a
pretty basic bug in the property stuff on ScriptableObject... (i'm running
1.5, but it looks like this code hasn't changed in CVS.) since it looks
like you're actively developing (even though it's been a while since
1.5...) i figured you might be interested -- apologies if i missed a more
formal bug reporting process...
the symptom was that i got a "Hashtable internal error" thrown from
getSlotToSet. reading the code, here's what i think could happen:
- create a new object (slots.length is initially 5)
- add 3 properties
- delete those 3 properties
(now count == 0, and slots[i] == REMOVED for 3 values of i)
- add 2 more properties
now assume that you're unlucky, and that these two hash to different values
than the first three; now you have 2 elements of slots[] containing real
slots, and the other three containing REMOVED.
now what happens when you try to create another slot? getSlotToSet is only
willing to put something in a null slot[], and you haven't got one, so you
get the internal error.
writing this message encouraged me to try to write a test case to reproduce
it, and in fact it's trivial:
js> x={}; x.a=x.b=x.c=1; delete x.a; delete x.b; delete x.c; x.d=x.e=1
1
js> x.whatever=1
(boom)
by the way, while reading the code i also noticed what looks like another,
less consequential bug: addSlot increments count before deciding to grow
the table, which is done with a recursive call, which will cause count to
be incremented again -- right? as far as i can tell, setting count too big
will only cause it to grow the table a little early next time, so it
doesn't really matter, but it looks wrong.
.mike.
* factored out some of the method dispatching code by adding a dispatchMethod() method to the controller;
* turned the Dispatcher class into simply a function on the base Service class and removed Dispatcher.pm;
* made it possible for services to be both services and objects and provide different services depending on which context they were called in (and used this to make the AdminCommands module actually do what it was intended to in the first place, namely, only work for CommandLine access);
* fixed it so if a service is first created by getServiceList the constructed version will actually be cached;
* made output more generic by allowing services to implement arbitrary parts of the output API, used that to make AdminCommands usable without requiring additional code to support it;
* added some documentation;
* added some dump(10) statements to help debugging;
* fixed the string datasource SQL;
* fixed the DBI database so it can handle errors;
* added tableExists API to the DBI database helper.
Thanks to myk, justdave and zach for some ideas.
relyea%netscape.com
sfraser%netscape.com
mscott%netscape.com
pschwartau%netscape.com
valeski%netscape.com
brade%netscape.com
alecf%netscape.com
locka%iol.ie
ben%netscape.com
rbs%maths.uq.edu.au
racham%netscape.com
ian%hixie.ch
guru%startrek.com
bienvenu%netscape.com
nboyd%atg.com
sdagley%netscape.com
radha%netscape.com
ccarlen%netscape.com
dbaron%fas.harvard.edu
hewitt%netscape.com
mcafee%netscape.com
blizzard%redhat.com
waterson%netscape.com
arik%netscape.com
bryner%uiuc.edu
cmanske%netscape.com
leaf%mozilla.org