• Bugs
  • [spine-c] Deadlock in binarySearch1

Hi,

I am using Spine software - and I just feel I have to say it: it is great 🙂

Recently I am getting a deadlock in function binarySearch1. It happens usually at the very beginning. It started to happened after I've upgraded spine-runtimes to:
https://github.com/EsotericSoftware/spi ... c0b1f1551c
and also happens with last available version:
https://github.com/EsotericSoftware/spi ... it/5ffee20
My current version of Spine is 2.0.17.

Here is the backtrace from the deadlock:

frame #0: 0x0018ab7c JuicyGlade`binarySearch1(values=0x18789fc0, valuesLength=1, target=NaN) + 104 at Animation.c:214
  frame #1: 0x0018aa90 JuicyGlade`_spAttachmentTimeline_apply(timeline=0x18789f90, skeleton=0x18777240, lastTime=-1, time=NaN, firedEvents=0x1876e8b0, eventsCount=0x27d899ec, alpha=1) + 256 at Animation.c:481
  frame #2: 0x001892b6 JuicyGlade`spTimeline_apply(self=0x18789f90, skeleton=0x18777240, lastTime=-1, time=NaN, firedEvents=0x1876e8b0, eventsCount=0x27d899ec, alpha=1) + 122 at Animation.c:107
* frame #3: 0x0018922e JuicyGlade`spAnimation_apply(self=0x18789f60, skeleton=0x18777240, lastTime=-1, time=NaN, loop=0, events=0x1876e8b0, eventsCount=0x27d899ec) + 242 at Animation.c:63
  frame #4: 0x001d28a8 JuicyGlade`spAnimationState_apply(self=0x1876e880, skeleton=0x18777240) + 240 at AnimationState.c:136
  frame #5: 0x001fcbea JuicyGlade`spine::SkeletonAnimation::update(this=0x1876e550, deltaTime=0.337050974) + 94 at SkeletonAnimation.cpp:126
  frame #6: 0x000caa1e JuicyGlade`BoundedSkeleton::update(this=0x1876e550, deltaTime=0.337050974) + 34 at BoundedSkeleton.cpp:131
  frame #7: 0x0019e08a JuicyGlade`cocos2d::CCScheduler::update(this=0x166680a0, dt=0.337050974) + 270 at CCScheduler.cpp:809
  frame #8: 0x00196b3c JuicyGlade`cocos2d::CCDirector::drawScene(this=0x16667920) + 48 at CCDirector.cpp:256
  frame #9: 0x00197cf8 JuicyGlade`cocos2d::CCDisplayLinkDirector::mainLoop(this=0x16667920) + 60 at CCDirector.cpp:1078
  frame #10: 0x001cc47e JuicyGlade`-[CCDirectorCaller doCaller:](self=0x16668580, _cmd=0x00315afb, sender=0x16689040) + 22 at CCDirectorCaller.mm:94
  frame #11: 0x006eca56 libglInterpose.dylib`-[DYDisplayLinkInterposer forwardDisplayLinkCallback:] + 270
  frame #12: 0x30d87df2 QuartzCore`CA::Display::DisplayLinkItem::dispatch() + 98
  frame #13: 0x30d87b9c QuartzCore`CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 344
  frame #14: 0x33b2175c IOMobileFramebuffer`IOMobileFramebufferVsyncNotifyFunc + 104
  frame #15: 0x2f58a450 IOKit`IODispatchCalloutFromCFMessage + 248
  frame #16: 0x2e85fef8 CoreFoundation`__CFMachPortPerform + 136
  frame #17: 0x2e86aab6 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 34
  frame #18: 0x2e86aa52 CoreFoundation`__CFRunLoopDoSource1 + 346
  frame #19: 0x2e869226 CoreFoundation`__CFRunLoopRun + 1398
  frame #20: 0x2e7d3f0e CoreFoundation`CFRunLoopRunSpecific + 522
  frame #21: 0x2e7d3cf2 CoreFoundation`CFRunLoopRunInMode + 106
  frame #22: 0x336f9662 GraphicsServices`GSEventRunModal + 138
  frame #23: 0x3111f16c UIKit`UIApplicationMain + 1136

Would you please take a look on that? If you need more data, please let me know - I will provide them.

thanks
Michal

Related Discussions
...
  • 編集済み

Do you mean an infinite loop? How did time get to be NaN? Can you reproduce the problem? If so, can you add checks for NaN anywhere time is changed? Make sure spAnimationState_update is never called with a NaN delta, timeScale is never NaN, Animation duration is never NaN, etc.

Yes, that is infinite loop. Thanks for hint. I will add some assertions and will get back with results.
regards


Shame on me, I found the problem on my side 🙁
thanks for help
Michal

Woohoo! I mean, glad you found it. 🙂