Thank you for the report. I can confirm the crash, we'll look into this.

- Kim

Hi nobu,

It looks like this crash happens only on the first call to renderFrameQCAR.

If you can wait until the second call of renderFrameQCAR onwards (using a static/class flag) the crash will be avoided.

- (void)renderFrameQCAR
{
...
static BOOL canUseFrame = NO;
if (canUseFrame == YES)
{
[INDENT]QCAR::Frame frame = state.getFrame();
NSLog(@"image num:%d", frame.getNumImages());
}
canUseFrame = YES;
[/INDENT]...
}

We'll continue looking for a solution in the meantime.

Thank you for the answer.
It checked operating correctly.

MoSR wrote:

Hi nobu,

It looks like this crash happens only on the first call to renderFrameQCAR.

If you can wait until the second call of renderFrameQCAR onwards (using a static/class flag) the crash will be avoided.

Hi MoSR. Do you happen to have a suggestion if I'm not using renderFrameQCAR? I'm using another iOS library to handle my scene management and rendering, which is a little more complex than a single render function call (renderFrameQCAR). Is there something else I can try to clear up the issue? Much thanks in advance.

Edit: Sorry, forgot to add my system specs:

Native SDK
Mac OS X 10.7.3
Xcode 4.3.2
iPhone 4
iOS 5.1
No modifications

I would suggest the same type of solution - just ignore the first detected frame in whatever rendering method you have.

Thanks for the reply MoSR. I already took a shot at what you said. Here is a snippet of my code:

- (void) tick:(float)dt
{
    // update QCAR
    QCAR::State state = QCAR::Renderer::getInstance().begin();
    
    static BOOL canUseFrame = NO;
    
    if (canUseFrame == NO)
    {
        canUseFrame = YES;
        QCAR::Renderer::getInstance().end();
        return;
    }
    
    QCAR::Frame currentFrame = state.getFrame();
     
    const QCAR::Image* image;
    
    // Crash happens in this for loop when trying to access getNumImages
    for ( int i = 0; i < currentFrame.getNumImages(); ++i )
    {
        image = currentFrame.getImage(i);

        // Do custom stuff here
    }
}

This will still signal the EXC_BAD_ACCESS. Without modifying any code, I've gotten past the initial for loop line once...but I forgot to add the data sets to the resources so the app did not work properly.

I'm still fairly confident it is the same issue as the original post, but I'm going to double check my initialization code while I wait for a response to this post. I'm using the QCARutils source provided in the examples, btw, if that helps out at all.

Ah, it turns out I did not fully initialize the camera. Once I started the camera and used the suggestion from this thread, everything is running well. Thanks for the help!

When I got Mr. MoSR to teach, it was operating, but it came to recur.
The test code which recurred is as follows.
------
- (void)renderFrameQCAR
{
[self setFramebuffer];

QCAR::setFrameFormat(QCAR::RGB888, true);

// Clear color and depth buffer
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

// Get the state from QCAR and mark the beginning of a rendering section
QCAR::State state = QCAR::Renderer::getInstance().begin();

static BOOL isFirstProc = YES;

if(!isFirstProc)
{
QCAR::Frame frame = state.getFrame();
NSLog(@"%d", frame.getNumImages()); //Thread 2:Program received signal:"EXC_BAD_ACCESS"
}
isFirstProc = NO;

////////////////////////////////////////////////////////////////////////////
// This section renders the video background with a
// custom shader defined in Shaders.h
QCAR::Renderer::getInstance().bindVideoBackground(0);

------
this problem occurs -- last time -- the same -- it is iPhone4/iOs4.3.5 (8L1).
In iPad2/iOs4.3.3, it does not start too (8J2).

I hate to recant my earlier success post, but the issue has repeated itself even with the static bool trick. It just happened to work two times in a row, which was good enough for me to pack up and head home. I just tried running again, with no code changes, and it crashed at the same spot.

I'm debugging it and trying a few more things. I understand what MoSR is getting at, so I'm going to try something else. As it stands, still crashing, so I will post again if I make any progress. Otherwise I'm stumped.

Okay - let us know how you get on. We'll look at it from our end and see if the fix we have queued is likely to solve the problem.

We're also experiencing this issue.

We almost always get a EXC_BAD_ACCESS on frame.getNumImages(), and I've tested on iPhone 4, iPhone 4S and iPad 2. All with iOS 5.1. Skipping the first frame doesn't make any difference.

When I tried the BackgroundTextureAccess sample, it seems to work better iPhone 4S (hasn't crashed yet) than on iPhone 4 (crashes every time).

A fix/workaround to this would be very appreciated. Thank you!

@MoSR - So bad news. My further attempts have resulted in failure. I could not find a single trick, delay, or "skip" that will allow me to avoid this crash. I really want to use the Frame object approach since it will fit well in my existing framework. I have a plan B for making use of the SDK, but it will require me to modify the internal rendering methods that might break the state system. It's already a really solid and functional framework, so I'm not looking forward to that kind of change.

I'll keep an eye on this thread to see if the team comes up with a fix while I work on an alternative approach to using Vuforia. All in all, I love the SDK and have no plans of switching, so long as Plan B works.

Just to clarify, here's what I want to do:

1. I want to get raw image data from the camera from your SDK.
2. I want to use my own OpenGL rendering methods instead of the ones provided by your SDK.

Preferably I would like to avoid even setting a EAGLContext in the renderFrameQCAR callback, since I'm not to use it.

Because of the issue discussed in this thread, I'm unable to get the raw camera data. Does anyone know if there's any other way to get it?

The thread below seems to describe similar issues, and a "UpdateCallback" is mentioned in the first post. Could that help me?
http://ar.qualcomm.at/node/2001390

Any help on this would be very appreciated. Thank you!

@GameDevMich:

Hi - we do have a candidate fix for this - but we need to make sure it solves the problem fully.

In all your workaround attempts (thanks for pursuing BTW) have you tried skipping, say, 10 frames?

In our tests, skipping just one frame was good enough - can you provide some sample code (by Private Message) that demonstrates the problem?

@andersfrank: please watch this thread - we'll hopefully get you out of your corner soon.

@GameDevMich, andersfrank, nobu:

I've taken the QCAR iOS SDK 1.5.8 release, accessed QCAR::Frame.getFrame().getNumImages() to cause the crash (it failed on the third time - the cause is an unitialised variable so it is somewhat random).

Then I applied the suggested workaround to skip the first frame and ran the app more than 20 times with no crash.

Can you provide any evidence (device log, Xcode stack trace and log, source code) from the crash you get having applied the workaround so we can establish if this is indeed the same issue?

Here's a crash log from BackgroundTextureAccess. I looked at a few, and they're all very similar, so it seems to be the exact same issue every time.

Incident Identifier: 624B3CEB-C8A1-41CD-8E1F-F5617E379984
CrashReporter Key: 8608ab0553d58e48ff9bc3237447ee1fd15e0693
Hardware Model: iPhone3,1
Process: BackgroundTextureAccess [3209]
Path: /var/mobile/Applications/BE87CF4C-08B7-4078-9A9C-51D54D4C8F13/BackgroundTextureAccess.app/BackgroundTextureAccess
Identifier: BackgroundTextureAccess
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]

Date/Time: 2012-04-25 17:31:58.157 +0200
OS Version: iPhone OS 5.1 (9B176)
Report Version: 104

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x30000000
Crashed Thread: 10

Thread 7 name: Dispatch queue: com.qualcomm.AR.videoqueue
Thread 7:
0 libsystem_kernel.dylib 0x34c18004 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x34c181fa mach_msg + 50
2 libsystem_kernel.dylib 0x34c18d4c thread_get_state + 88
3 libobjc.A.dylib 0x36258018 _collecting_in_critical + 120
4 libobjc.A.dylib 0x36257b64 _cache_collect + 28
5 libobjc.A.dylib 0x36256ed8 _cache_fill + 468
6 libobjc.A.dylib 0x362567c4 lookUpMethod + 172
7 libobjc.A.dylib 0x36257bae class_respondsToSelector + 22
8 CoreFoundation 0x34d88e3e -[NSObject respondsToSelector:] + 26
9 AVFoundation 0x319a422c __74-[AVCaptureVideoDataOutput _AVCaptureVideoDataOutput_VideoDataBecameReady]_block_invoke_0 + 196
10 libdispatch.dylib 0x30e59c52 _dispatch_call_block_and_release + 6
11 libdispatch.dylib 0x30e64ca4 _dispatch_queue_drain + 268
12 libdispatch.dylib 0x30e64b12 _dispatch_queue_invoke$VARIANT$up + 30
13 libdispatch.dylib 0x30e65784 _dispatch_worker_thread2 + 208
14 libsystem_c.dylib 0x36adfdf4 _pthread_wqthread + 288
15 libsystem_c.dylib 0x36adfcc8 start_wqthread + 0

Thread 10 Crashed:
0 BackgroundTextureAccess 0x0000bfd4 QCAR::Frame::getNumImages() const + 20
1 BackgroundTextureAccess 0x0000a8a0 -[EAGLView renderFrameQCAR] (EAGLView.mm:130)
2 CoreFoundation 0x34d937cc -[NSObject performSelector:] + 32
3 BackgroundTextureAccess 0x00118348 0x1000 + 1143624
4 BackgroundTextureAccess 0x00119164 0x1000 + 1147236
5 libsystem_c.dylib 0x36ae572e _pthread_start + 314
6 libsystem_c.dylib 0x36ae55e8 thread_start + 0

Please see the attached image.

@MoSR - I tried the following approaches:

1. Single boolean (as suggested in this thread)
2. An integer counter, which I tested with 3, 4, 5, 6, etc
3. A timer that would pause in certain intervals to let QCAR do whatever it needed to do in the background
4. Moving the code from my tick function into renderframeqcar, then repeat 1-3.

I could not get past the crash in any of the above steps.

Here's a link to my crash log: Pastebin crash log

Here's my console output:

[QUOTE" />Apr 26 16:38:50 unknown armouse[2266" /> : APPSTATUS_INIT_TRACKER
Apr 26 16:38:50 unknown armouse[2266" /> : Successfully initialized ImageTracker.
Apr 26 16:38:50 unknown armouse[2266" /> : APPSTATUS_INIT_APP_AR
Apr 26 16:38:50 unknown armouse[2266" /> : APPSTATUS_LOAD_TRACKER
Apr 26 16:38:50 unknown armouse[2266" /> : INFO/AR(2266) 2012-04-26 16:38:50: ImageTracker: Successfully created dataset
>
Apr 26 16:38:51 unknown com.apple.debugserver-64[2263" /> : 1 [08d7/0303" />: error: ::mach_vm_read ( task = 0x1603, addr = 0x00000000, size = 512, data => 0x00000000, dataCnt => 0 ) err = (os/kern) invalid address (0x00000001)
Apr 26 16:38:51 unknown com.apple.debugserver-64[2263" /> : 2 [08d7/0303" />: error: ::mach_vm_read ( task = 0x1603, addr = 0x00000000, size = 512, data => 0x00000000, dataCnt => 0 ) err = (os/kern) invalid address (0x00000001)
Apr 26 16:38:51 unknown com.apple.debugserver-64[2263" /> : 3 [08d7/0303" />: error: ::mach_vm_read ( task = 0x1603, addr = 0x00000000, size = 512, data => 0x00000000, dataCnt => 0 ) err = (os/kern) invalid address (0x00000001)
Apr 26 16:38:51 unknown com.apple.debugserver-64[2263" /> : 4 [08d7/0303" />: error: ::mach_vm_read ( task = 0x1603, addr = 0x00000000, size = 512, data => 0x00000000, dataCnt => 0 ) err = (os/kern) invalid address (0x00000001)
Apr 26 16:38:51 unknown com.apple.debugserver-64[2263" /> : 5 [08d7/0303" />: error: ::mach_vm_read ( task = 0x1603, addr = 0x00000000, size = 512, data => 0x00000000, dataCnt => 0 ) err = (os/kern) invalid address (0x00000001)
Apr 26 16:38:51 unknown com.apple.debugserver-64[2263" /> : 6 [08d7/0303" />: error: ::mach_vm_read ( task = 0x1603, addr = 0x00000000, size = 512, data => 0x00000000, dataCnt => 0 ) err = (os/kern) invalid address (0x00000001)
Apr 26 16:38:51 unknown com.apple.debugserver-64[2263" /> : 7 [08d7/0303" />: error: ::mach_vm_read ( task = 0x1603, addr = 0x00000000, size = 512, data => 0x00000000, dataCnt => 0 ) err = (os/kern) invalid address (0x00000001)
>
Apr 26 16:38:55 unknown UserEventAgent[12" /> : TRACE: connection interrupted
Apr 26 16:38:55 unknown UserEventAgent[12" /> : DEBUG: disconnected
Apr 26 16:38:55 unknown UserEventAgent[12" /> : TRACE: Canceling
Apr 26 16:38:55 unknown UserEventAgent[12" /> : TRACE: connection invalid
>
Apr 26 16:41:17 unknown wifid[13" /> : WiFi:[357176477.802502" />: Disable WoW requested by "spd"
Apr 26 16:41:18 unknown spd[2273" /> : spd:spd_vet_socket:658 getpeername failure for client socket [FD=4" />: Socket is not connected
Apr 26 16:41:18 unknown spd[2273" /> : spd:spd_checkin_socket:954 Unable to check-in unsupported socket for client [PID=1944" />
>
Apr 26 16:41:43 unknown wifid[13" /> : WiFi:[357176503.241023" />: Disable WoW requested by "spd"[/QUOTE" />

@GameDevMich: Note that your pastebin log indicates that the crash occurs on the main thread. The renderframeqcar is called on a background thread, and all calls to the QCAR renderer needs to be done on that specific thread (according to the docs).

@GameDevMich: As andersfrank astutely noted, this crash looks different to the original, which crashes within the Render thread.

Are you trying to run some part of the rendering in a different thread - all sorts of things won't like that.

You *do* have to perform any iOS/Cocoa calls on the main thread, so some switching may be required if you have a complicated interaction between OpenGL and iOS UI.

@GameDevMich: Your crash seems to be much earlier than the first frame render as you should have the following status logged before that is called:

QCAR OpenGL flag: 2
QCARutils onCreate()
APPSTATUS_INIT_APP
APPSTATUS_INIT_QCAR
autofocus: 1, autofocusContinuous: 1, torch 1
INFO/AR(205) 2012-04-27 14:18:56: QCAR SDK version 1.5.8
QCARutils onResume()
APPSTATUS_INIT_TRACKER
Successfully initialized ImageTracker.
APPSTATUS_INIT_APP_AR
APPSTATUS_LOAD_TRACKER
INFO/AR(205) 2012-04-27 14:18:56: ImageTracker: Successfully created dataset
Successfully loaded data set.
Successfully activated data set.
INFO/AR(205) 2012-04-27 14:18:56: ImageTracker: Successfully created dataset
Successfully loaded data set.
APPSTATUS_INITED
APPSTATUS_RESUMED
APPSTATUS_CAMERA_RUNNING
DEBUG/AR(205) UIView has CAEAGLLayer class
DEBUG/AR(205) UIView responds to selector renderFrameQCAR

@MoSR - Hm. I'm going to kick myself for days if this is due to me not reading the docs well enough. Alright, I'm going to move some code around to see if I can do this the right way. Much thanks for pointing out my potential logic failure. I will report back in a couple of hours when I get to the office.

Alright, I seem to be making progress. I tried a different approach which is more in line with the examples and suggestions in this post. Rather than trying to access QCAR data on the main thread in my tick function, I am utilizing renderFrameQCAR to get the information I need. Here is my new code:

[CODE" />- (void)renderFrameQCAR
{
static BOOL canUseFrame = NO;

QCAR::setFrameFormat(QCAR::RGB888, true);

QCAR::State state = QCAR::Renderer::getInstance().begin();

if (canUseFrame == YES)
{
QCARutils* qUtils = [QCARutils getInstance" />;

QCAR::Frame currentFrame = state.getFrame();

const QCAR::Image* image;

// Crash consistently happens here.
for(int i = 0; i {
image = currentFrame.getImage(i);

if(image)
{
[qUtils setCurrentImage:image" />;
qUtils.readyToRender = YES;
break;
}
}
}

canUseFrame = YES;

QCAR::Renderer::getInstance().end();
}[/CODE" />

I'm still crashing, but it's no longer happening on the main thread. The initialization output is now happening before the first render call:

[QUOTE" />2012-04-27 09:57:09.499 armouse[3092:707" /> APPSTATUS_INIT_TRACKER
2012-04-27 09:57:09.517 armouse[3092:707" /> Successfully initialized ImageTracker.
2012-04-27 09:57:09.518 armouse[3092:707" /> APPSTATUS_INIT_APP_AR
2012-04-27 09:57:09.520 armouse[3092:707" /> APPSTATUS_LOAD_TRACKER
2012-04-27 09:57:09.523 armouse[3092:5d0b" /> INFO/AR(3092) 2012-04-27 09:57:09: ImageTracker: Successfully created dataset
2012-04-27 09:57:09.928 armouse[3092:5d0b" /> Successfully loaded data set.
2012-04-27 09:57:09.930 armouse[3092:5d0b" /> Successfully activated data set.
2012-04-27 09:57:09.932 armouse[3092:5d0b" /> INFO/AR(3092) 2012-04-27 09:57:09: ImageTracker: Successfully created dataset
2012-04-27 09:57:10.140 armouse[3092:5d0b" /> Successfully loaded data set.
2012-04-27 09:57:10.173 armouse[3092:707" /> APPSTATUS_INITED
2012-04-27 09:57:10.174 armouse[3092:707" /> APPSTATUS_CAMERA_RUNNING
2012-04-27 09:57:10.195 armouse[3092:707" /> DEBUG/AR(3092) UIView has CAEAGLLayer class
2012-04-27 09:57:10.198 armouse[3092:707" /> DEBUG/AR(3092) UIView responds to selector renderFrameQCAR[/QUOTE" />

Here's the new crash log: Crash log

Hopefully I'm reading the logs correct and not missing something. I'm tempted to ditch QCARUtils all together and manually set everything up in the hopes that there is some initialization step I've missed. Any further feedback based on this post?

Sorry to spam the thread, but I have concluded it most certainly has something to do with my code. The static bool workaround solves the issue in an existing example, such as BackgroundTextureAccess.

My code must not fully initialize QCAR, so I'm going to put the app together piece by piece without using QCarUtils. If someone sees anything wrong with my current code or the posted logs that might point me in the right direction, any further advice will be appreciated.

I seem to have identified the problem.

Skipping the first cycle fixes in BackgroundTextureAccess the problem, but if comment out the line "[self setFramebuffer];" in EAGLView.mm:renderFrameQCAR it crashes.

Hence, not having a valid framebuffer object bound to the current context seems to cause the problem.

I'll now be able to fix this in my project. But in the best of worlds, I would like to be able to fetch the frames without even setting up a context. Hope you'll be able to identify the bug :)

I've now rewritten my view to handle it's own context. It hasn't crashed yet, fingers crossed.

Here's some code that may be helpful for anyone with the same issue. It's specifically written not to interfere with the main thread context (if there is one).
http://pastebin.com/N5AAfQnf

Edit: I was wrong. It still crashes, but it's a lot better. It's gone from crashing every time to like 1 in 5. Maybe it isn't about the existence of the framebuffer, but rather about that the framebuffer takes some time to setup, which will incur a small delay.. I'll keep investigating..

Edit2: After skipping the first FIVE frames (instead) of just the first, it seems to be even more stable. It hasn't crashed yet, after like 30 runs. Even the BackgroundTextureAccess sample crashed once when I just skipped the first frame, so it's definitely some kind of bug in the framework. I've updated the pastebin url above with the minor modification.

Thanks for the update, andersfrank. Good to know you have found what appears to be a viable workaround. Please keep us posted if the problem returns.

Hi,

We've been tracking the original problem on this thread, and although we have applied a 10 frame delay before accessing the Frame object, we still occasionally and randomly see the EXC_BAD_ACCESS error in the same place.

Is there a solution for this available yet?

hi guys,

the below solution works for me.

first checking if the camera is running gets around the getFrame() issue.

next, get the image pointer reference using getImage() and check if its non NULL.

if so, you are good to go.

    State state = Renderer::getInstance().begin();

    Renderer::getInstance().drawVideoBackground();

    if([QCARutils getInstance].appStatus == APPSTATUS_CAMERA_RUNNING) {

        Frame frame = state.getFrame();

        const Image * image = frame.getImage(0);

        if(image) {

            cameraWidth = image->getBufferWidth();

            cameraHeight = image->getBufferHeight();

            cameraPixels = (unsigned char *)image->getPixels();

        }

    }

    Renderer::getInstance().end();

Thanks for sharing :)

N

Can someone from QC please comment on this BAD_ACCESS problem? Is this a framework problem or not?

It is really difficult to track down and since the result is crashing apps I think it is pretty severe....

Hi tgotzsche

Do you still get a problem when you add this line?

 if([QCARutils getInstance].appStatus == APPSTATUS_CAMERA_RUNNING)