Just run this little test program: #include <stdlib.h> #include <JavaScriptCore/JavaScript.h> static JSValueRef jsGet_prop (JSContextRef jsCtx, JSObjectRef jsObj, JSStringRef jsName, JSValueRef* jsExn) { return JSValueMakeNumber (jsCtx, 42.0); } static bool jsSet_prop (JSContextRef jsCtx, JSObjectRef jsObj, JSStringRef jsName, JSValueRef jsVal, JSValueRef* jsExn) { return true; } static JSClassRef create_class (void) { static const JSStaticValue vals[] = { { "a", jsGet_prop, jsSet_prop, kJSPropertyAttributeDontDelete }, { NULL, NULL, NULL, 0 } }; JSClassDefinition cdef = kJSClassDefinitionEmpty; cdef.className = "FooObject"; cdef.staticValues = vals; return JSClassCreate (&cdef); } int main (void) { JSClassRef jsClass; JSGlobalContextRef jsCtx; JSStringRef jsScript; jsScript = JSStringCreateWithUTF8CString ("// blah blub!"); jsClass = create_class (); jsCtx = JSGlobalContextCreate (jsClass); /* Boom! */ JSEvaluateScript (jsCtx, jsScript, NULL, NULL, 0, NULL); return EXIT_SUCCESS; } /* Local Variables: compile-command: "gcc -g -ggdb -O0 -W -Wall \ `pkg-config --cflags --libs webkit-1.0` \ jseval.c -o jseval" End: */ $ ./jseval ASSERTION FAILED: index < m_size (JavaScriptCore/VM/SegmentedVector.h:82 T& KJS::SegmentedVector<T, SegmentSize>::operator[](size_t) [with T = KJS::RegisterID, unsigned int SegmentSize = 512u]) segmentation fault
I'm seeing the assertion failure on Mac OS X, too. Not being a JavaScriptCore API expect, I'm not sure if this is a bug or expected behavior for this usage.
Feels more like a bug though, confirming.
(In reply to comment #2) > Feels more like a bug though, confirming. > I should have added some more words... Was a bit tired. This is just the shortest test case I came up with. It doesn't depend on the implementation of the getter / setters. w/o assertions enabled it produces the weirdest things (I discovered this when I managed to define `undefined' to some function) but usually it just segfaults. Linking against electric fence (w/ disabled assertions) results in a seg fault in the hash table code. I suspect the symbol table of the global object is completely foobared. This started after updating from SVN yesterday, didn't happen before (about 1 week old version from svn). Hope this helps a bit to narrow it down.
Created attachment 22030 [details] naive fix
Comment on attachment 22030 [details] naive fix Why not use new [] and OwnArrayPtr for registerArray? Why not have JSVariableObjectData inherit from Noncopyable rather than reimplementing it? Seems OK, as-is. r=me
(In reply to comment #5) > Why not have JSVariableObjectData inherit from Noncopyable rather than > reimplementing it? Confusingly, Noncopyable didn't work for me, I was getting a compiler error ('class WTFNoncopyable::Noncopyable' is inaccessible). I couldn't figure out why.
Comment on attachment 22030 [details] naive fix This patch looks good to me, too. In the long term, though, we should just get rid of JSGlobalObject::reset -- we no longer need to support resetting a global object.
Committed revision 34946 (changed registerArray to OwnArrayPtr).