Bad access error in EAGLView.mm

I’m getting an error in my game.

EXC_BAD_ACCESS (code=1, address=0x1) in EAGLView.mm line 319

if(![context_ presentRenderbuffer:GL_RENDERBUFFER])  ***Error
{
//         CCLOG(@"cocos2d: Failed to swap renderbuffer in %s\n", __FUNCTION__);
}

The error seems to occur both randomly and after I resume from my pause menu. My pause system simply hides/shows the UI and pauses/resumes the action manager though so I don’t know how this could affect it. My game is very simple and i’m not doing anything with view controllers. Other than basic sprites I’m doing just a few opengl renders myself. Why might this be occuring? I’d be happy to supply any more information. I’m using cocos2d-x v2.1

Thanks!

Edit:: more information below

2 Likes

@jhooks098

Weird errors, but the information you provided here is not sufficient for me to identify what’s wrong with EAGLView.

You’d better provide more information, such as the stack trace or some codes or screenshot.

@0owen

No problem

At each phase, (path ***'d)

-(void) doCaller: (id) sender
{
    ***cocos2d::CCDirector::sharedDirector()->mainLoop();
}
void CCDisplayLinkDirector::mainLoop(void)
{
    if (m_bPurgeDirecotorInNextLoop)
    {
        m_bPurgeDirecotorInNextLoop = false;
        purgeDirector();
    }
    else if (! m_bInvalid)
     {
         ***drawScene();
     
         // release the objects
         CCPoolManager::sharedPoolManager()->pop();        
     }
}
void CCDirector::drawScene(void)
{
    // calculate "global" dt
    calculateDeltaTime();

    //tick before glClear: issue #533
    if (! m_bPaused)
    {
        m_pScheduler->update(m_fDeltaTime);
    }

    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

    /* to avoid flickr, nextScene MUST be here: after tick and before draw.
     XXX: Which bug is this one. It seems that it can't be reproduced with v0.9 */
    if (m_pNextScene)
    {
        setNextScene();
    }

    kmGLPushMatrix();

    // draw the scene
    if (m_pRunningScene)
    {
        m_pRunningScene->visit();
    }

    // draw the notifications node
    if (m_pNotificationNode)
    {
        m_pNotificationNode->visit();
    }
    
    if (m_bDisplayStats)
    {
        showStats();
    }

    kmGLPopMatrix();

    m_uTotalFrames++;

    // swap buffers
    if (m_pobOpenGLView)
    {
        ***m_pobOpenGLView->swapBuffers();
    }
    
    if (m_bDisplayStats)
    {
        calculateMPF();
    }
}
void CCEGLView::swapBuffers()
{
    ***[[EAGLView sharedEGLView] swapBuffers];
}
if(![context_ presentRenderbuffer:GL_RENDERBUFFER])
        {
         CCLOG(@"cocos2d: Failed to swap renderbuffer in %s\n", __FUNCTION__);
        }

Other than this I don’t really have any specific code to go off of but i’m looking. Its so strange in what situation might context_ have false access?

I also meet the same problems. I’m using cocos2d-x 2.2.1

Also happens randomly using version 3.10. Any idea how to debug it?

I’m using 3.9 and I can replicate this issue 100% by minimizing (pressing the hardware button on the iphone) the app WHILE THE SPLASH SCREEN IS PRESENTED.

According to this old post in cocos2d forum:

http://forum.spritebuilder.com/t/cocos2d-and-inter-app-audio-crash/12580

it is caused by

In the app delegate you have to delay the [window_ makeKeyAndVisible]; line so that it only runs if the app is in the foreground, otherwise you run it the first time the app is returned to the foreground via -(void) applicationWillEnterForeground:(UIApplication*)application.

I put this very stupid piece of code in the AppController.m

// make key and hid status bar
UIApplicationState appstate;
do
{
    appstate = [UIApplication sharedApplication].applicationState;
    if(appstate != UIApplicationStateBackground)
    {
        [window makeKeyAndVisible];
    }
} while(appstate == UIApplicationStateBackground);

and this prevents the crash, but when I resume the app, the view is not presented and the app won’t start.

Maybe this will help somebody to find a fix for this.

On a side note, I’ve been using cocos since 2.2.6 and I’ve always received crash logs about this crash. I think this issue has been around for a long time? Glad I found a way to reproduce it btw.

Davide