Greetings!
I'm in now way associated with Spine or Esoteric, but...
My team has strict rules about memory leaks and memory tracking and we use a custom memory tracker as well as several other commercial trackers. I've written a memory leak detector that's now a part of the Spine-C Unit testing. Check out spine-c/spine-c-unit-tests/memory for more details.
The leaks that I've found have been plugged, and were in the KB range, not GB.
Blind bleeding the blind
The first step is to determine what is leaking. XCode has instruments, which I find extremely useful for tracking leaks:
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/FindingLeakedMemory.html
This should catch most C/C++/Objective-C code leaks including bad ARC usage.
However, OpenGL ES leaks can be quite devastating too. Make sure that the texture objects are being freed correctly:
https://developer.apple.com/library/content/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/ToolsOverview/ToolsOverview.html#//apple_ref/doc/uid/TP40008793-A2
Unpacked RGBA surfaces that conform to POW2 requirements take up a lot of space. A simple 1024x768 image sits on a 1024x1204 texture and takes up 4 MB. (3MB on RGB 24 bit surface). If I were leaking Gigs, textures would be my first bet.
Stop the Open GL frame on the second scene and inspect ALL objects to see if scene 1 is still hanging around.
The blame game
Once you figure out what is leaking, you can track down who is leaking it. First, inspect and trace the entire lifetime of the object to see if there is some sort of leak. Check Destructors, Move and Copy Constructors, SmartPointers (for atomic access violations), etc... Also, I think Cocos2dx has a texture cache. Make sure that it's getting hit for the same texture and that garbage collecting is working.
A little research shows that Cocos2dx does have memory leak issues. One thread points to GLFW as the culprit.
Memory is the cause and solution to all my problems
Sometimes memory leaks are grouped together around a single object. You might leak several objects and only solving the leak of a single object will take care of the rest.
Also, check that crash. There might be an infinite loop allocating memory...
Throw a debug break point before changing back to scene 1 and walk through until you get the crash. Use stepping and break points to zero in on the exact crash point. (I use something like a binary search by dividing code sections in half)