Home/ Questions/Q 7928491
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-03T19:44:55+00:00

I’ve recently converted my iOS project to ARC. I have two targets in my

  • 0

I’ve recently converted my iOS project to ARC. I have two targets in my project. One is the application itself, and the other is a set of GHUnit tests. I have approximately 200 tests that do quite a lot of work in terms of creating and modifying Core Data objects. The Core Data store used by the tests is an in memory store, and is thrown away once the tests are finished (i.e. it is not persisted anywhere).

When my tests have been running a while (they never reach the exact same point before the error is thrown, but it is always around the same tests) the application crashes with an EXC_BAD_ACCESS (Code=2, address=…)

The output in the console is as follows:
Console Output

I’ve followed the instructions here in this answer, and set my main.m file of the GHUnit target to use the -fno-objc-arc compiler flag, but that doesn’t seem to have helped.

I don’t really understand what these errors mean, and searching for them doesn’t seem to have helped. My only guess is that I am running out of memory, but I’m not sure why or how, considering ARC should be releasing objects for me.

I’d really appreciate any help anyone can give me to fix this! If you have any questions just leave me a comment and I will get back to you asap!

Thanks!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Chris,

    First, As you have a memory exhaustion problem, you should look at your tests running under the Instruments allocation tool. Remember to turn on VM automatic snapshots. Then you should mark the heap multiple times as the tests execute.

    Second, while this may be related to ARC, it quite possibly isn’t. In general, ARC apps, because they can automatically release objects sooner, have a smaller footprint than MRR apps. The move to a new compiler with different options may just be uncovering a pre-existing problem.

    Third, because you are using an in-memory database, my first test would be to just change it to a SQLite DB. It can have a much smaller footprint. (While you may choose to return to in-memory DBs later, we’re trying to find the cause of your memory exhaustion. An in-memory DB can use a lot of RAM. Hence, lets take is out of the equation.

    Once you’ve done the 1st and 3rd tasks above, please report back your results.

    Andrew

    • 0