Intermittent crashing creating a Persistent object.

[loude...@gmail.com]

Any ideas why I'm seeing an intermittent crash here?  It happens during a stress test for Adobe Character Animator (v8 version: 9.4.146.24).  This call is made 1000s of times in our app and occasionally there's a crash.

     Character Animator (Beta).exe!v8::internal::GlobalHandles::Create(class v8::internal::Object)    Unknown
     Character Animator (Beta).exe!v8::internal::GlobalHandles::Create(unsigned __int64)    Unknown
     Character Animator (Beta).exe!v8::V8::GlobalizeReference(class v8::internal::Isolate *,unsigned __int64 *)    Unknown
>    [Inline Frame] Character Animator (Beta).exe!v8::PersistentBase<v8::Object>::New(v8::Isolate *) Line 10971    C++
     [Inline Frame] Character Animator (Beta).exe!v8::Persistent<v8::Object,adobe_v8::utils::PersistentTraitsT<v8::Object>>::{ctor}(v8::Isolate *) Line 682    C++
     Character Animator (Beta).exe!adobe_v8::makePersistent(v8::Isolate * isolate, v8::Local<v8::Object> object, boost::shared_ptr<void> * dataDeleterPP, void(*)(const v8::WeakCallbackInfo<std::pair<boost::shared_ptr<void> *,adobe_v8::utils::PersistentP<v8::Object>>> &) callback) Line 1508    C++
     Character Animator (Beta).exe!adobe_v8::CreatePersistentData(v8::Isolate * inIsolateP, v8::Local<v8::Object> obj, boost::shared_ptr<void> dataDeleterP) Line 1548    C++
     Character Animator (Beta).exe!adobe_v8::AttachPersistentDataToInstance(v8::Isolate * inIsolateP, v8::Local<v8::Object> instance, void * dataP, boost::shared_ptr<void> dataDeleterP) Line 1583    C++

The thread 0x8c4 has exited with code 0 (0x0).
<31172> <ExportStageVideoTask> <5> Number of export render threads: 4
Exception thrown at 0x000000014105BACA in Character Animator (Beta).exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.

[loude...@gmail.com]

Anyone??

[Leszek Swirski]

This is unfortunately too little detail to go on, my best guess would be that you're passing in an invalid Isolate pointer (something to do with lifetimes in the embedder?). Also note that you're using a 1-year old version of V8.

[loude...@gmail.com]

Yeah, we are out of date and I will attempt to upgrade soon.  But, I do think there's a threading issue here that's very intermittent.  I did read other posts that describe problems if you don't call Reset on the persistent object.  See any problems here?

    typedef std::pair<DataDeleterP*, utils::PersistentP<v8::Object> > PeristentWeakDataPair;
    typedef v8::WeakCallbackInfo<PeristentWeakDataPair> PersistentWeakData;

    static
    utils::PersistentP<v8::Object> makePersistent(v8::Isolate *isolate, v8::Handle<v8::Object> object, DataDeleterP* dataDeleterPP, PersistentWeakData::Callback callback) {
        utils::PersistentP<v8::Object> persistentObjP(new PERSISTENT_BASE(v8::Object)(isolate, object));
        persistentObjP->SetWeak(new PeristentWeakDataPair(dataDeleterPP, persistentObjP), callback, v8::WeakCallbackType::kParameter);
        return persistentObjP;
    }

    static
    void releasePersistent (const PersistentWeakData& data)
    {        
        PeristentWeakDataPair* paramPairP = data.GetParameter();

        delete paramPairP->first;
        paramPairP->second->Reset();
        paramPairP->second.reset();
        delete paramPairP;

        #ifdef ADOBE_V8_DEBUG_V8_ALLOCATIONS
            DecrementV8AllocCount();
        #endif

[dinf...@chromium.org]

Hi,

Those persistent/global handles are single-threaded only, could it be that you allocate such handles from multiple threads?

There is also v8::Global which Reset()s itself in the destructor automatically. We would even like to remove v8::Persistent entirely at some point (see https://bugs.chromium.org/p/v8/issues/detail?id=12915&q=v8%3A%3APersistent&can=2).

Cheers,

Dominik

[Jim Acquavella]

Oh, single-threaded.  I would have expected v8 to use a mutex around their persistent (global handle) management.  I'll try a mutex on my side and see if that resolves the issue.  Thanks for your help.  🤞

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to a topic in the Google Groups "v8-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-users/Pg5OPm7uPFY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to v8-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/a95e8264-8f5a-4b5c-9e14-410982a61683n%40googlegroups.com.

[loude...@gmail.com]

A mutex around our persistent creation alone didn't solve this problem.  Removing v8::Persistent and replacing them with v8::Global is not ideal, since we reuse these Persistent objects across multiple contexts to cache common function/object templates.  

[ibon]

I recently had a problem where a Persistent was being initialised in one Isolate which was then disposed. I accidentally kept an initialised Persistent around and got an immediate crash when calling Persistent Reset after creating a 2nd Isolate.

In my case I was neglecting to Reset properly one Persistent handle. 

The weak callback was properly invoked, and on destruction I was also walking the heap for tagged Persistent objects (isolate->VisitHandlesWithClassIds) but the culprit was the lack of one single Persistent Reset.

Maybe worth a look.