2014-09-15 9 views
46

Weiß jemand, was diese Art von Ausnahme auf iOS 8 ist?App heruntergefahren mit EXC_RESOURCE, WAKEUPS Ausnahme auf iOS 8 GM

=== von Absturzbericht ===

Exception Type: EXC_RESOURCE 
Exception Subtype: WAKEUPS 
Exception Message: (Limit 150/sec) Observed 206/sec over 300 secs 
Triggered by Thread: 14 

scheint nur geschehen auf iOS 8 ... Unsere App nach unten ganz zufällig in beliebigen Intervallen mit dieser Ausnahme ..

geschlossen ist Beliebig Hinweise sind willkommen. Vielen Dank!

+0

Haben Sie Glück dabei? Ich bekomme den gleichen Fehler mit dem Täter: 'Thread 4 Name: WebThread' – ohhh

+0

Ich habe genau den gleichen Fehler. Verwenden von Xamarin und OpenTok –

+0

Wir haben ein ähnliches Problem mit unserer App, die mit dem, was Ryan unten gesagt hat, verwandt sein kann. Im Grunde spielen wir Sound-Effekte mit SKAction playSoundFileNamed: aber manchmal, nach dem Zufallsprinzip, spielt es keinen Sound, es sei denn, Sie beenden die App und setzen sie später wieder fort, dann spielt alles auf einmal, was darauf hindeutet, dass etwas diese Aktionen blockiert ... Wenn du in diesem Zustand eine Weile weiter spielst, wirst du diesen Absturz schließlich sehen ... – gzafra

Antwort

18

Ihre App sendet häufig einen Weckbefehl an einen bestimmten Thread in der App - scheinbar durchschnittlich 206 Mal pro Sekunde. Hintergrundthreads in iOS 8 haben eine harte Grenze dafür, wie oft Sie einen Schlaf/Wach-Zyklus für jeden Thread pro Sekunde ausführen können, und eine hohe Anzahl hier ist normalerweise ein Hinweis darauf, dass etwas in Ihrem Thread-Management falsch/ineffizient ist.

Ohne Ihren Code zu sehen, ist meine Empfehlung, dass Sie Ihre C++ - Algorithmen für Sleep/Wake-Aufrufe überprüfen oder den Hintergrundprozess Multithread, um neue Threads in jedem Zyklus zu starten.

Ray Wenderlich eine fantastische Tutorial auf der Apple-System für Multi-Threading hat, Grand Central Dispactch, die auch eine gute Ressource für Sie sein könnten: http://www.raywenderlich.com/60749/grand-central-dispatch-in-depth-part-1

+0

Gibt es eine Möglichkeit, die Anzahl der Weckrufe für einen bestimmten Thread zu kontrollieren und zu begrenzen? Denn der laufende Thread wird anscheinend nach der Arbeit zum Stillstand kommen, es gibt keinen Grund mehr, ihn so oft aufzuwecken! –

+0

Können Sie ein Beispiel im Code angeben, das mir hilft, dieses Problem besser zu verstehen? –

+0

Könnte die Verwendung von @ synchronized in Hintergrund-Threads dieses Problem verursachen? –

2

Mit Xamarin haben wir dieses Problem auch. Wir haben 4 SemaphoreSlim benutzt, die gleichzeitig zu lange gewartet haben. Ersetzen des SemaphoreSlim durch eine andere primitive Synchronisation (AutoResetEvent in unserem Fall, um einen Semaphor von 1 Element zu simulieren) behob das Problem. Ich sehe nicht, alle Verweise auf GPUTools

0

In meinem Fall auf ios 9.1 wird dies durch Gewinde 2 ausgelöst, die einige Arbeiter für die GLES Fahrer Ursache der Suche durch die Projektquellen zu sein scheint.

Thread 2 name: gputools.smt_poll.0x145722df0 
Thread 2 Attributed: 
0 libsystem_kernel.dylib   0x000000019a8b7440 __semwait_signal + 8 
1 libsystem_c.dylib    0x000000019a7c9e2c nanosleep + 212 
2 libsystem_c.dylib    0x000000019a7c9d4c 0x19a7bc000 + 56652 
3 GPUToolsCore     0x0000000100ba0ae0 0x100b98000 + 35552 
4 libsystem_pthread.dylib   0x000000019a97fb28 _pthread_body + 156 
5 libsystem_pthread.dylib   0x000000019a97fa8c _pthread_body + 0 
6 libsystem_pthread.dylib   0x000000019a97d028 thread_start + 4 

sehen: iOS 7 and OpenGL issues/crashes ich Fehler 23.389.472 mit Apfel abgelegt habe, Ursache in meinem Fall ist dies kein Thread I oder einig 3rd-Party-Code erstellt, und thusly, das ist sehr wahrscheinlich ist das nicht mein Fehler. Das Endergebnis ist: wenn der anstößige Thread dein ist (das schließt natürlich Software von Drittanbietern ein), dann gilt Ryans Antwort. Ansonsten haben Sie entweder , um Apple zu kontaktieren und/oder in der Zwischenzeit nach einer Problemumgehung zu suchen.

Verwandte Themen