iOS flash-back analysis due to multithreading

A while ago, I made an app and encountered a strange flashback during the test.

This app is about sound processing: The device is recording while the sound is being processed. So it takes 2 threads, one thread saves the recording and the other handles the saved sound. Test, will be within the 1~10min, irregular, no omen of the situation of the Flash, the report of the wrong is also different, there are

1) "Nsgenericexception ' Collection is mutated while being enumerated"

Or:

2) "Pointer being freed is not allocated"

There are also flash messages that indicate too much memory:

3) "Crash due to memory pressure"

And the more The Heavenly book was played:

4) "First Throw call stack:

(0X30170ECB 0x3a907ce7 0x301709b9 0x4a177 0x40a97 0x30b5bab5 0x3013bf0f 0x3013bb2b 0x30139eb3 0x300a4729 0x300a450b 0x350 036d3 0x32a05871 0x4f4b9 0x3ae05ab7) "

and time requirements and more urgent, really a bit of a burn. After more than 1 days of research, these problems were one by one fixed.

First of all, 3rd, it is obvious that the memory was generated and not released. Hey, objective-c not have arc, automatic processing memory ah, for a long time not because of memory troubles. But the sound processing is relatively low-level, with the C language, on this part of the memory, arc can not help. Processing is not troublesome, first with instruments positioning, which leak of memory, and then to all malloc out of the memory block, ran out of free. Try again, the increase in memory is slowing down.

1th, "Collection is mutated while being enumerated" means that an object (usually Nsarray or something) is changed when it is accessed, causing the program to hang. In my program, this object is to store the sound data, for the moment it is called data. The 1th thread will continuously write the new data to it and delete the old data. On the 2nd thread, the contents of data are read and processed periodically. Because these two threads are relatively short each time they manipulate data, they are not very common at the same time, so the general program can persist for a few minutes. However, once they operate/access data at the same time, the program is hung up.

The solution is also very simple, there is a syntax in objective-c, specifically dealing with such things: @synchronized (parameter) {code block}

When the parameters of the two @synchronized code block are the same, the two code blocks cannot be manipulated at the same time. For parameters, we often use self to make arguments. For example:

Thread 1:

@synchronized (self) {

Write Data

}

Thread 2:

@synchronized (self) {

Read data

}

When thread 1 is writing data, thread 2 can wait. This avoids the problem of flash-back when simultaneous simultaneous reading/writing of global data blocks is possible.

2nd, "Pointer being freed is not allocated", but also because of multi-threaded simultaneous writing data problems, but there are some special. Data contains only the most recent time, when the data is stored too much, it will be deleted, and then save the new data. The problem is that thread 1 calls very fast and reaches 1 seconds 50 times. Sometimes the last call to a is not over, the next call to B comes again, this time it may be a problem: a detected data in too many, the oldest data deleted. However, do not wait for a to actually delete the data, B again, it will be the oldest data deleted, so the same data will be free two times, the compiler will call: "The hands of the code is empty, you also want to Lao Tzu, I do not dry!"

Solution above, also add a @synchronized, this block of data, to tell the compiler: in order to ensure the quality of service, each time only to a thread to provide services, and so on a big uncle comfortable, and then let the next come in.

Finally, sometimes the compiler will be jerking off, just tell you, "I'm going to hang up!" "(exc_bad_access), and then vomit out a whole lot of excrement:

"First throw Call stack:

(0X30170ECB 0x3a907ce7 0x301709b9 0x4a177 0x40a97 0x30b5bab5 0x3013bf0f 0x3013bb2b 0x30139eb3 0x300a4729 0x300a450b 0x350 036d3 0x32a05871 0x4f4b9 0x3ae05ab7) "

As programmers, we're going to find the cause of the compiler from this heap of excrement and see what it eats:

Add this function to the APPDELEGATE.M:

void Uncaughtexceptionhandler (NSException *exception) {

NSLog (@ "CRASH:%@", exception);

NSLog (@ "Stack Trace:%@", [exception callstacksymbols]);

Internal Error Reporting

}

And then:

– (BOOL) Application: (UIApplication *) application didfinishlaunchingwithoptions: (Nsdictionary *) launchOptions {

Nssetuncaughtexceptionhandler (&uncaughtexceptionhandler);

}

That way, when the compiler hangs up, it prints something like this:

0 corefoundation 0x30c16f9b <redacted> + 154,
1 LIBOBJC. A.dylib 0X3B491CCF Objc_exception_throw + 38,
2 corefoundation 0x30b4da39 <redacted> + 176,
3 TEST 0x001ce2c9-[testbaseviewcontroller viewdidload] + 848,

We can see that the problem is in the [Testbaseviewcontroller viewdidload] Function (please ignore the next +848, I don't know what it means, and nobody seems to know). Although it is not possible to navigate to a specific line, it is at least a greatly reduced range.

There's also a tip about crash targeting: Crazy NSLog around all the places where you suspect there will be a flashback, so that when you're back, you'll soon be able to pinpoint where you're going.

For programmers, locating a problem means that the problem is solved by 90%.

iOS flash-back analysis due to multithreading