get a crash by movieclip

Comments

• Xman Member

  January 2017 edited January 2017

  Reading the code, it looks like the bug might be that Sprite.cpp's destructor just unref() its children, while it should also clear their parent link to NULL!
  
  EDIT: Just did that and the example you gave above no longer crashes!

  This change may be necessary. I have committed it in pull request #296
  
  

  +1 -1Share on Facebook
• Xman Member

  January 2017 edited January 2017

  And also after revert, It may be necessary to call stop() in MovieClip's destructor function to prevent it from crash.
  
  Edit:it maybe not required, MC will stop itself after collected.

  +1 -1Share on Facebook
• hgy29 Maintainer

  January 2017

  @Xman: for your review: https://github.com/gideros/gideros/commit/35e395899e4b9b924878a72fd40f00e96cc9a6ad

  +1 -1Share on Facebook
• Xman Member

  January 2017 edited January 2017

  @hgy29
  maybe you should also check again the change in the lua binder code.
  It's not easy to determine if unref is needed when call stop in lua if the unref is not done in the stop function.
  I see the reason you do not directly unref in stop maybe because of the loop in nextFrame.
  Maybe you can consider to put it into an autounref pool in stop to unref it in next run loop just like remove a child do.Then only the play and stop functions require modified,all the other modifications can just be reverted to the original.

  +1 -1Share on Facebook
• hgy29 Maintainer

  January 2017 edited January 2017

  Thanks, its true I forgot the unref() in lua binder. Let me fix this. I cannot use autounrefpool since its implementation seems to release objects immediately when destroying the pool, I mmuch more confident on propagating the unref() request back to the frame event as I did. But I'll remove this dependance from luabinding somehow.

  +1 -1Share on Facebook
• Xman Member

  January 2017 edited January 2017

  Yes, a local pool can not retain the unref objects until next run loop.
  I thought there would be a thread-scope pool like autorelease pool exists, but no.

  +1 -1Share on Facebook
• Xman Member

  January 2017 edited January 2017

  Is that simpler to understand, just let holdWhilePlaying_ to determine ref and unref to avoid memory problems by abuse the parameter of stop.

  bool MovieClip::stop() { passoneframe_ = false; if (playing_) { playing_ = false; removeEventListener(EnterFrameEvent::ENTER_FRAME, &MovieClip::nextFrame); if (holdWhilePlaying_) //play ref, stop unref { unref(); } return holdWhilePlaying_; //indicated whether unref has done } return false; }       void MovieClip::nextFrame(EnterFrameEvent *) { switch (type_) { case eFrame: oneFrame() break; case eTime: { double curr = iclock(); int delta = (curr - prevClock_) * 1000; prevClock_ = curr;   delta = std::min(std::max(delta, 0), 1000);   for (int i = 0; i < delta; ++i) if (oneFrame()) { return; } break; } } }

  +1 -1Share on Facebook
• hgy29 Maintainer

  January 2017 edited January 2017 Accepted Answer

  Well if I unref() too early, the MC will be freeed at once so the code will no longer be able to read properties or call other methods without crashing, so its best to propagate the information as much as possible so as to free just before the final 'return'.
  
  BTW I appreciate a lot your contributions to the code, we are too few guys to maintain Gideros, thanks for that!

  Likes: MoKaLux

  +1 -1 (+1 / -0 )Share on Facebook
• Xman Member

  January 2017 edited January 2017

  yes, you're right. I did not notice the MC still need to do something after call stop )

  +1 -1Share on Facebook