Bug 19834 – Failed assertion in JavaScriptCore/VM/SegmentedVector.h:82

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[David Hansen]

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

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

Feels more like a bug though, confirming.

[David Hansen]

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

[Alexey Proskuryakov]

Created attachment 22030 [details]
naive fix

[Darin Adler]

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

[Alexey Proskuryakov]

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

[Geoffrey Garen]

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.

[Alexey Proskuryakov]

Committed revision 34946 (changed registerArray to OwnArrayPtr).