Geek Answers Handbook

IPhone simulator crash using WebPreferences in thread list

Apple Developer Reference Library contains a class reference for WebPreferences

I searched SO, Dev Forums and Googled without any relevant results.

EXC_BAD_ACCESS signal is generated.

I can not find the crash report .. this happens on the simulator. The debugger is called and I do not receive a crash report.

EDIT

This is triggered when UITextField pressed, when exiting UITextField or if UITextField set as the first responder when loading a view (pressed by the navigation controller).

This is not easy to reproduce. I can go through a hundred application start / debug cycles before this happens again. And then this can happen 3 times in 5 starts.

I have a list of threads in the debugger that shows some links to WebPreferences.

alt text

+7
iphone ios-simulator
source share
5 answers

You are on the right track if you are using NSZombie . EXEC_BAD_ACCESS caused by access to released objects.

For EXEC_BAD_ACCESS, this is normal if you do not get into code paths that do not belong to you. Most likely, your code created a re-released object.

A key part of using NSZombie is malloc_history on the command line. You will receive a call stack showing where the reissued object came from. For example: alt text http://static.benford.name/malloc_history.png

The screenshot shows that my application breaks into [NSString stringByTrimmingCharactersInSet:] , but this, of course, did not cause a crash.

I use the method to look at the earliest code path that you have. In most cases, the error is there.

In this case, the object came from the class [JTServiceHttpRequest requestFinished] , in which I did not save the object properly.

If all else fails, review all of the code codes listed and make sure that you are using the correct memory management rules.

My bet is that the behavior of WebPreferences and UITextField has nothing to do with the failure.

+1
source share

For any EXC_BAD_ACCESS errors, you usually try to send a message to the issued object. The BEST way to track these actions is used by NSZombieEnabled .

This works by never releasing any object, but completing it as a “zombie” and setting a flag inside it that says it would normally be released. Thus, if you try to access it again, he still knows what it was before you made a mistake, and with this little information you can usually backtrack to find out what the problem is.

This is especially helpful in background threads when the debugger sometimes tricks into any useful information.

IT IS VERY IMPORTANT TO NOTE , however, you need to be 100% sure that this is only in your debugging code and not in your distribution code. Since nothing is ever released, your application will flow, flow and flow. To remind me to do this, I injected this log into my appdelegate:

 if(getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled")) NSLog(@"NSZombieEnabled/NSAutoreleaseFreedObjectCheckEnabled enabled!");

If you need help finding the exact string, do Build-and-Debug ( CMD-Y ) instead of Build-and-Run ( CMD-R ). When the application crashes, the debugger will show you which line, and in combination with NSZombieEnabled, you should know exactly why.

+1
source share

The fact that it crashes in _integerValueForKey: makes me strongly suspect that it crashes on a reissued NSNumber. Re-issuing an NSNumber can lead to such strange crashes that it is almost humorous. Here's what happens:

  • You create an NSNumber for the integer "2"
  • NSNumber class caches NSNumber
  • You reissue it
  • NSNumber class cache now indicates bad memory
  • Some completely unrelated piece of code creates an NSNumber for the integer "2"
  • The NSNumber class looks for it in the cache and ....
  • Bang

If you are using Snow Leopard, press Cmd-Shift-A to have the analyzer look for memory management issues. Otherwise, go hunting for the use of NSNumbers.

0
source share

agreed with previous respondents about NSZombie. This most often happens when you use your class as a delegate to a UITextView (or any other class) and also reference it in the IBOutlet variable. when you leave your view manager - it is freed. but if you did not issue the IBOutlet variable in the - (void) dealloc method - the UITextView will still send calls to the freed delegate (your view controller).

0
source share

Sounds more like an Auto-Release bug. Perhaps you are releasing what you do not “own” and the NSAutoRelease pool is running and trying to clear what has already been released?

Did you release something that you didn't “distribute”? For example, you would not do:

 NSString *test = @"testing"; [test release];

Since this will cause a crash when starting the automatic release pool and trying to free NSString.

0
source share

More articles:


All Articles