Asked  7 Months ago    Answers:  5   Viewed   16 times

When deploying the application to the device, the program will quit after a few cycles with the following error:

Program received signal: "EXC_BAD_ACCESS".

The program runs without any issue on the iPhone simulator, it will also debug and run as long as I step through the instructions one at a time. As soon as I let it run again, I will hit the EXC_BAD_ACCESS signal.

In this particular case, it happened to be an error in the accelerometer code. It would not execute within the simulator, which is why it did not throw any errors. However, it would execute once deployed to the device.

Most of the answers to this question deal with the general EXC_BAD_ACCESS error, so I will leave this open as a catch-all for the dreaded Bad Access error.

EXC_BAD_ACCESS is typically thrown as the result of an illegal memory access. You can find more information in the answers below.

Have you encountered the EXC_BAD_ACCESS signal before, and how did you deal with it?



From your description I suspect the most likely explanation is that you have some error in your memory management. You said you've been working on iPhone development for a few weeks, but not whether you are experienced with Objective C in general. If you've come from another background it can take a little while before you really internalise the memory management rules - unless you make a big point of it.

Remember, anything you get from an allocation function (usually the static alloc method, but there are a few others), or a copy method, you own the memory too and must release it when you are done.

But if you get something back from just about anything else including factory methods (e.g. [NSString stringWithFormat]) then you'll have an autorelease reference, which means it could be released at some time in the future by other code - so it is vital that if you need to keep it around beyond the immediate function that you retain it. If you don't, the memory may remain allocated while you are using it, or be released but coincidentally still valid, during your emulator testing, but is more likely to be released and show up as bad access errors when running on the device.

The best way to track these things down, and a good idea anyway (even if there are no apparent problems) is to run the app in the Instruments tool, especially with the Leaks option.

Tuesday, June 1, 2021
answered 7 Months ago

You'll need to add an UITapGestureRecogniser and assign it to the view, and then call resign first responder on the UITextField on it's selector.

The code:

In viewDidLoad

UITapGestureRecognizer *tap = [[UITapGestureRecognizer alloc] initWithTarget:self action:@selector(dismissKeyboard)];

[self.view addGestureRecognizer:tap];

In dismissKeyboard:

    [aTextField resignFirstResponder];

(Where aTextField is the textfield that is responsible for the keyboard)

Swift 3 version looks like that

let tapGesture = UITapGestureRecognizer(target: self, action: #selector(self.dismissKeyboard (_:)))

For dismissKeyboard

@objc func dismissKeyboard (_ sender: UITapGestureRecognizer) {
Tuesday, June 1, 2021
answered 7 Months ago

See if you are getting the following error when your App starts.

Application windows are expected to have a root view controller at the end of application launch

If so the way to fix it is by making the following change in the AppDelegate.m file (although there seem to be a number of answers how to fix this):

// Replace
[self.window addSubview:[navigationController view]];  //OLD

// With
[self.window setRootViewController:navigationController];  //NEW

After this shouldAutoRotate should be correctly called.

Wednesday, June 9, 2021
answered 6 Months ago

The first signal is SIGHUP; that gets sent to all processes in the process group when the terminal disconnects (hangs up - hence HUP).

The second signal is SIGCONT (thanks, SiegeX, for the numbers). This is slightly surprising; it suggests you had a job stopped in the background which had to be allowed to run again.

The third signal is another SIGHUP. This was likely sent to ensure that the continued process got its turn to exit, but was sent to the whole process group. (See the POSIX standard for information on process groups, etc.).

The fourth signals is a SIGCHLD, indicating that a child process died and the corpse is available (well, the status is available).

The final signal, 0, is the shells internal pseudo-signal indicating that it is exiting.

You can do:

trap 'echo Bye' 0

to echo 'Bye' when the shell exits under control for any reason. You chose to echo the signal number to the file instead. Since the shell exits at this point, that is the last signal message that is seen. Its parent process should get a SIGCHLD signal because the shell died.

FWIW, on MacOS X 10.6.7, I ran your test. There isn't a signal 32 on MacOS X, and some of the mappings are different, and the sequence of signals sent is also different:

$ i=-1;while((++i<33));
> do
>     trap "echo $i >> log.txt" $i;
> done
-sh: trap: 32: invalid signal specification
$ trap
trap -- 'echo 0 >> log.txt' EXIT
trap -- 'echo 1 >> log.txt' HUP
trap -- 'echo 2 >> log.txt' INT
trap -- 'echo 3 >> log.txt' QUIT
trap -- 'echo 4 >> log.txt' ILL
trap -- 'echo 5 >> log.txt' TRAP
trap -- 'echo 6 >> log.txt' ABRT
trap -- 'echo 7 >> log.txt' EMT
trap -- 'echo 8 >> log.txt' FPE
trap -- 'echo 9 >> log.txt' KILL
trap -- 'echo 10 >> log.txt' BUS
trap -- 'echo 11 >> log.txt' SEGV
trap -- 'echo 12 >> log.txt' SYS
trap -- 'echo 13 >> log.txt' PIPE
trap -- 'echo 14 >> log.txt' ALRM
trap -- 'echo 15 >> log.txt' TERM
trap -- 'echo 16 >> log.txt' URG
trap -- 'echo 17 >> log.txt' STOP
trap -- 'echo 19 >> log.txt' CONT
trap -- 'echo 20 >> log.txt' CHLD
trap -- 'echo 23 >> log.txt' IO
trap -- 'echo 24 >> log.txt' XCPU
trap -- 'echo 25 >> log.txt' XFSZ
trap -- 'echo 26 >> log.txt' VTALRM
trap -- 'echo 27 >> log.txt' PROF
trap -- 'echo 28 >> log.txt' WINCH
trap -- 'echo 29 >> log.txt' INFO
trap -- 'echo 30 >> log.txt' USR1
trap -- 'echo 31 >> log.txt' USR2

The signals captured in one run were:


In a second run, I got:


The SIGINT first is surprising -- I don't think I can explain that unless it simply means an incomplete write of some sort (it should have read 20 but the SIGHUP caused a problem). I'm not sure that I can explain the SIGCHLD signals either; the SIGHUP and 'exit' trap are as before.

To some extent, though, the signals are system specific - or so it seems. The SIGHUP is common and constant, though.

Thursday, June 24, 2021
answered 6 Months ago

As you are using Windows, SIGTERM handler is useless, more reference:

On Windows, the C runtime implements the six signals that are required by standard C: SIGINT, SIGABRT, SIGTERM, SIGSEGV, SIGILL, and SIGFPE.

SIGABRT and SIGTERM are implemented just for the current process.

But you could use signal.CTRL_BREAK_EVENT as an alternative.

I.e. create a signal handler in that handles SIGBREAK, but send the CTRL_BREAK_EVENT from the parent. Also, make sure to start your subprocess using creationflags=subprocess.CREATE_NEW_PROCESS_GROUP (otherwise it will kill the parent as well)

app = subprocess.Popen("python", shell=True, creationflags=subprocess.CREATE_NEW_PROCESS_GROUP)

while 1:
    p = app.poll()
    if p is not None:

exit = False

def exit_signal_handler(signal, frame):
    global exit
    print("Terminate signal received")
    exit = True

signal.signal(signal.SIGBREAK, exit_signal_handler)
while not exit:
Tuesday, August 17, 2021
answered 4 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :