iOS: : post enviado a la instancia desasignada Error de debugging

Estoy trabajando en una aplicación de iOS (iOS 7)

En el que estoy ejecutando Javascript en UiWebView varias veces

Pero muchas veces (random)

**** Me sale este error con error [CFRunLoopTimer release]: post enviado a la instancia desasignada

**** y, a veces, error como este: **** ** webthread locking de subprocesss múltiples no permitido ******

Me he asegurado de que a la vez solo un hilo realice una acción en UIWebview

He intentado ejecutar la operación en cada subprocess y queue (subprocess de background, subprocess principal y diferentes queues globales) (pero sin éxito)

Al perfilar la aplicación y reproducir el crash en Instruments (modo zombie) recibo este post Error de reproducción del mensaje del instrumento

He comprobado a background mi javascript (es 100% correcto).

Pero sigo recibiendo este error muchas veces.

¿Alguien puede decirme cómo resolver este problema? ¿Alguna solución o consejo para depurar este error? (Ya he configurado NSZombienabled = YES), pero esto también es de ninguna ayuda.

He estado atrapado con este mismo error por un time también.

Al igual que lo hice, probé prácticamente todo, desde NSOperationQueue's addOperationWithBlock: a dispatch_async para performSelectorOnMainThread:withObject:waitUntilDone: … ( performSelectorOnMainThread:withObject:waitUntilDone: en la oscuridad)

Entonces pensé que siempre estaba llamando a mi código js usando [myJsContext evaluateScript:jsString]; , y obteniendo el JSContext de UIWebView utilizando [myWebView valueForKeyPath: @"documentView.webView.mainFrame.javaScriptContext"]; .

En su lugar, probé el antiguo [myWebView stringByEvaluatingJavaScriptFromString:jsString]; , y parece funcionar ahora (al less no se ha estrellado en mucho time).

Entonces, ¿tal vez esa sea una solución, ya que también estás usando UIWebViews? Mi entendimiento es que evaluateScript: es especialmente útil si está utilizando un JSContext sin una UIWebView.

(Esta respuesta puede carecer de certezas técnicas reales, así que por favor, investigue si sabe más sobre JavaScriptCore … Pero, ¡parece que simplemente funciona para mí!)

He pensado que esto se interrumpe, simplemente llame a un stringByEvaluatingJavaScriptFromString ficticio en la UIWebView antes de invocar un método en el context. Creo que la razón por la que esto funciona es que la llamada a javascript se realiza en el subprocess web y utiliza un timer para recibir la respuesta de vuelta al subprocess principal, al invocar no se creó este timer, por lo que cuando la respuesta vuelve de la Web El subprocess se bloquea al intentar lanzar un timer que nunca se creó en primer lugar. Al utilizar la API apropiada stringByEvaluatingJavaScriptFromString en se asegura que se crea el timer y luego invokeMethod puede utilizar el mismo timer.

 JSContext* context = [webView valueForKeyPath:@"documentView.webView.mainFrame.javaScriptContext"]; JSValue* value = context[@"Colors"]; // timer CFRelease crash fix [webView stringByEvaluatingJavaScriptFromString:nil]; [value invokeMethod:@"update" withArguments:@[objectID,modifier]]; 

Sugiero que encuentre todos los NSTimer en su proyecto y observe si algún object lo libera dos veces. Por lo tanto, puede establecer puntos de interrupción en cada método donde se libera el timer y ver cuando algún método llama a esta versión.

La segunda sugerencia es: Usar profiler para asignar todos los objects y, por supuesto, activar NSZombie.

Solo debe llamar a los methods en UIWebView desde el hilo principal. UIWebView no es thread safe y los methods de llamada de varios subprocesss no son seguros.

Dijiste: "He asegurado que en un momento solo un subprocess realice acciones en UIWebview": esto no es suficiente, por desgracia. Porque: usted no es el único que hace llamadas en la vista web. Hay timeres de runloop. Está el usuario tocando la vista web. Y otras cosas están sucediendo.