NME SVN iOS crash

Just FYI: after building NME from SVN using Lion and iOS SDK 5.0, I have had a crash at app launch on an iOS device, but not in the iOS simulator or any other cpp target. This occurred yesterday as well, but after rebuilding the latest it does the same. …

Viewing 1 to 14 (14 Total)
NME SVN iOS crash

crayfellow

crayfellow
Total Posts: 204
Joined: November 28, 2011

Just FYI: after building NME from SVN using Lion and iOS SDK 5.0, I have had a crash at app launch on an iOS device, but not in the iOS simulator or any other cpp target. This occurred yesterday as well, but after rebuilding the latest it does the same.

Here is the stack with -Ddebug at libnme build:http://pastebin.com/v0hSgpaX

After building libnme with -Ddebug I see it going a few steps further, into QuickVec. The first line of this method is where it finally crashes:


inline void Grow()
{
if (mSize>=mAlloc)
{
if (QBUF_SIZE_!=0 && mPtr==mQBuf)
{
mPtr = (T_ *)malloc(sizeof(T_)*(QBufSize*2));
memcpy(mPtr, mQBuf, sizeof(mQBuf));
mAlloc = QBufSize*2;
}
else
{
if (mAlloc)
mAlloc *= 2;
else
mAlloc = 16;
mPtr = (T_*)realloc(mPtr, sizeof(T_)*mAlloc);
}
}
}


It appears mSize is null after being set to inRHS.mSize;, but I'm just at the guessing stage right now.

Tags:
Posted on February 23, 2012 at 1:23 PM

crayfellow

crayfellow
Total Posts: 204
Joined: November 28, 2011

Re: NME SVN iOS crash

The crash appears to originate when 'Line' in RenderCommon.h calls sTransitions[y0].mX.push_back(Transition(x >> 10, diff));.

It happens to have the following values consistently when the crash occurs:

x: 404681 (so x >> 10 is 395)
diff: 1
y0: 73
last: 74
dy: 2
mMaxX: 405504
(meaning, Transition is being constructed with inX of 395 and inVal of 1)

As one might expect, commenting out this line runs fine, but no lines are drawn to the screen smiling

Patrick

Posted on February 23, 2012 at 5:55 PM

crayfellow

crayfellow
Total Posts: 204
Joined: November 28, 2011

Re: NME SVN iOS crash

here is the state of the SpanRect at the moment of the crash (breakpoint in Line just before the sTransitions[y0].mX.push_back(Transition(x >> 10, diff)); call)"

this nme::SpanRect *const 0x2feea35c
mAA int 4
mAAMask int -4
mLeftPos int 0
mMaxX int 405504
mMinX int -1024
mWinding int 1
mRect nme::Rect
x int 0
y int 0
w int 396
h int 80

The call then creates this Transition:

this nme::Transition *const 0x2feea0c4
x int 395
val short 1

and calls a push_back on a QuickVec with a mSize that has not yet been initialized:

this nme::QuickVec<nme::Transition,16> *const 0x00002914
mPtr nme::Transition *
mQBuf nme::Transition [16]
mAlloc int
mSize int

Posted on February 23, 2012 at 6:34 PM

Huge

Huge
Total Posts: 548
Joined: October 07, 2011

Re: NME SVN iOS crash

Hi,
This is probably a bug in the QuickVec class, which is designed to avoid memory overhead.
The problem is, is that it does not like bing moved - and now I look at it, it could be being moved by the vector resize. (I think there is a bug in the textfield usage too).
You could try adding this to the span rect constructor to make sure no move is required:

if (sTransitionsBuffer.size() < mRect.h)
{
sTransitionsBuffer.reserve(4096); // <- Add this line here
sTransitionsBuffer.resize(mRect.h);
sTransitions = &sTransitionsBuffer[0];
}

If this works for you, I will put in a better fix.

Hugh

Posted on February 23, 2012 at 7:25 PM

crayfellow

crayfellow
Total Posts: 204
Joined: November 28, 2011

Re: NME SVN iOS crash

cool, I will give that a try shortly!

Posted on February 23, 2012 at 8:50 PM

crayfellow

crayfellow
Total Posts: 204
Joined: November 28, 2011

Re: NME SVN iOS crash

bummer, I've got that line in the SpanRect constructor and find the same crash. This occurs both in the simulator and on a device.

I have it narrowed down to a drawRect call. If I don't let the app go any further during view initialization, it "runs" without crashing. Uncomment the drawRect, and the crash occurs. It only takes one, and appears to be happening the first time any graphics draw happens.

Posted on February 23, 2012 at 9:35 PM

crayfellow

crayfellow
Total Posts: 204
Joined: November 28, 2011

Re: NME SVN iOS crash

I tried this from scratch just now on a fresh Lion VM. iOS 5.0 SDK.

Using Joshua's hxcpp from the NME 3.2.1 installer, sdl-static from SVN, and NME from SVN, I built the command line tools, then built NME for iphoneos and iphonesim.

Running in this completely separate, fresh environment I have the same crash, so I believe this to be consistent based upon what is in SVN.


I have also boiled this down to a simple example that readily and consistently exhibits this issue, results that I believe match what Joshua was seeing yesterday with Lion and 5.0 SDK.

Just a simple main function like:

public static function main () {
nme.Lib.current.graphics.beginFill(0x000033, 0.5);
nme.Lib.current.graphics.drawRect(0.0, 0.0, 50, 50);
nme.Lib.current.graphics.endFill();
}

or:

public static function main () {
var s = new nme.display.Sprite();
s.graphics.beginFill(0x003300, 0.5);
s.graphics.drawRect(0.0, 0.0, 50, 50);
s.graphics.endFill();

nme.Lib.current.stage.addChild(s);
}

will draw a rectangle to the screen on other cpp targets, but both in the iOS simulator and on a device, it does not crash BUT nothing is rendered. I believe this to be the same bug that will turn into the crash with more display list depth, or perhaps whether or not it develops into the crash depends on timing.

Because the iOS 5.0 SDK has been the default production SDK for months (in the hands of developers as far back as last Summer) I think of this as a somewhat urgent issue as it prevents developers from building NME from SVN. It is for that reason and not only because this affects my own mission-critical project that I would like to offer whatever I can do to help us overcome this.

Thanks!
Patrick

Posted on February 24, 2012 at 9:17 AM

crayfellow

crayfellow
Total Posts: 204
Joined: November 28, 2011

Re: NME SVN iOS crash

I have it boiled down to any graphics call that engages the software renderer. The non-displaying rectangles aforementioned were simply caused by stage.align, stage.scaleMode, and stage.quality not being set yet in my test program. Once those were set the rectangles displayed as expected without a crash.

To make it crash, just set cacheAsBitmap true. This Main class is all it takes:

package ;

import nme.display.StageQuality;
import nme.display.StageAlign;
import nme.display.StageScaleMode;

class Main {
public function new () {
}

// application entry point
public static function main () {
// prepare stage configuration
nme.Lib.current.stage.align = StageAlign.TOP_LEFT;
nme.Lib.current.stage.scaleMode = StageScaleMode.NO_SCALE;
nme.Lib.current.stage.quality = StageQuality.BEST;

var sprite1 = new nme.display.Sprite();
sprite1.cacheAsBitmap = true;
sprite1.graphics.beginFill(0xaaaaaa, 0.5);
sprite1.graphics.drawRect(0.0, 0.0, 500, 500);
sprite1.graphics.endFill();
nme.Lib.current.addChild(sprite1);
}
}

Posted on February 24, 2012 at 12:14 PM

crayfellow

crayfellow
Total Posts: 204
Joined: November 28, 2011

Re: NME SVN iOS crash

Since they sound SO similar (identical) I suspect this is the same bug as the one folks are finding on Windows, such as graphics.drawTriangle and cacheAsBitmap bugs and BitmapData.draw() cpp crash.

Posted on February 24, 2012 at 5:18 PM

Huge

Huge
Total Posts: 548
Joined: October 07, 2011

Re: NME SVN iOS crash

Hi,
It might be different from the graphics.drawtriangles - since I do not use that code much.
I have tried your test code on my ipad, and it does not crash.
However, because of f*ing apple's complete disregard for backwards compatibility, I can install xcode 4.2 because I can't install lion because I have a CoreDuo, not a Core2Duo. So my guess is it is either a genuine bug (eg, uninitialized memory) that is only showing up on armv7, or perhaps some bad interaction between armv6 and armv7 code.
I will have a poke around later and see if I can get the armv7 libraries compiled through and see if that makes a difference.
Have you tried it with armv6 code?

Hugh

Posted on February 25, 2012 at 9:03 AM

crayfellow

crayfellow
Total Posts: 204
Joined: November 28, 2011

Re: NME SVN iOS crash

Right, it's not the drawTriangles, but both of those refer to a separate crash occurring when cacheAsBitmap is true. It's confusing because one of those refers to two separate crashes as far as I can tell.

Definitely, I had tried it with armv6 both in the standard haxelibs as well as ndll's compiled entirely by me (using the 5.0 SDK, it is all I've ever used compiling NME). I have been using NME extensively over the past two months with 8000 lines of haXe in my latest project and this is the first time I have encountered a genuine blocking issue, but it's a blocker to our project not to be able to build my own ndll's from source.

I'm not certain this has to do with Lion. I have noticed all of the build scripts assume SDK 4.2 and that is quite out of date. I use SDK 5.0 and always edit the build scripts to refer to the 5.0 path. So, I think it's more likely to do with the addition of ARC (automatic reference counting), the way retain/release and the auto release pool is handled differently in iOS 5.0 than in prior versions.

I definitely wouldn't recommend building with 4.2 any more as the average developer is highly likely to have 5.0 these days, particularly now that Xcode is distributed via the app store as an app, no longer just as an installer.

Thanks Hugh! Let me know what I can do. Joshua and I have been discussing setting up continuous integration so all targets are built automatically by Linux, Windows, and OS X build servers. This way, you wouldn't have to worry what you have locally because the server would determine the environment. Stuff like this would be a whole lot easier to root out. I am talking with a friend at a large ISP who may be willing to donate a dedicated server to use as the build master. I may even have an extra Xserve that I can contribute as a build slave to cover iOS builds if I can work out the security details (it is inside our LAN but accessible to the outside).

Patrick

Posted on February 25, 2012 at 9:24 AM

Huge

Huge
Total Posts: 548
Joined: October 07, 2011

Re: NME SVN iOS crash

Hi,
Without being able to regenerate the crash, I have looked over the code and noticed a potential bug that was introduced be the refactoring of the software render code. For me, this does not fix anything (because it is not broken), but hopefully it may do the trick for you. See if the latest update helps.

Hugh

Posted on February 25, 2012 at 8:58 PM

crayfellow

crayfellow
Total Posts: 204
Joined: November 28, 2011

Re: NME SVN iOS crash

Nicely done, that was it!!

This will likely resolve the cacheAsBitmap crash others are seeing on Windows x64!

Thanks, Hugh.

Patrick

Posted on February 26, 2012 at 8:38 AM

Moczan

Moczan
Total Posts: 26
Joined: December 18, 2011

Re: NME SVN iOS crash

Hey, I've just seen this post, how can I get the working version to test if it resolves the Windows problem I've posted about in the other topic?

Posted on February 28, 2012 at 3:03 PM