Катастрофа CoreTelephony

Я получаю этот след от TestFlight относительно одной интересной катастрофы.

Насколько я понял, сбои приложения в какой-то момент, когда использование CoreTelephony . Это может быть возможно из кого-то "запрос", в то время как пользователь использует применение?

К моему знанию применение не использует Структуру CoreTelephony . Причина Исключения SIGSEGV , и нить катастрофы 0

Спасибо!

PRIMARY THREAD THREAD 0

0 GPIreland 0x00113a1a testflight_backtrace + 238
1 GPIreland 0x00114704 TFSignalHandler + 264
2 libsystem_c.dylib 0x359d1e92 _sigtramp + 42
3 CoreTelephony 0x330078b4  + 32
4 CoreFoundation 0x333465de __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 14
5 CoreFoundation 0x33346290 __CFRunLoopDoTimer + 272
6 CoreFoundation 0x33344f00 __CFRunLoopRun + 1232
7 CoreFoundation 0x332b7ebc CFRunLoopRunSpecific + 356
8 CoreFoundation 0x332b7d48 CFRunLoopRunInMode + 104
9 GraphicsServices 0x3b0b52ea GSEventRunModal + 74
10 UIKit 0x3ab732f8 UIApplicationMain + 1120
11 GPIreland 0x00036f8a main (main.m:4)
12 GPIreland 0x0000d5a7 start + 39
Hide Other Threads

COM.APPLE.NSURLCONNECTIONLOADER

0 CoreFoundation 0x33344da2 __CFRunLoopRun + 882
1 CoreFoundation 0x332b7ebc CFRunLoopRunSpecific + 356
2 CoreFoundation 0x332b7d48 CFRunLoopRunInMode + 104
3 Foundation 0x34ed7bcc +[NSURLConnection(Loader) _resourceLoadLoop:] + 308
4 Foundation 0x34f5b67c __NSThread__main__ + 972
5 libsystem_c.dylib 0x359aa310 _pthread_start + 308
6 libsystem_c.dylib 0x359aa1d7 thread_start + 7
COM.APPLE.CFSOCKET.PRIVATE

0 libsystem_c.dylib 0x359aa1d7 thread_start + 7
THREAD 10

0 libsystem_c.dylib 0x3599f8a3 start_wqthread + 7
THREAD 11

0 libsystem_c.dylib 0x3599f8a3 start_wqthread + 7
WEBTHREAD

0 CoreFoundation 0x33344da2 __CFRunLoopRun + 882
1 CoreFoundation 0x332b7ebc CFRunLoopRunSpecific + 356
2 CoreFoundation 0x332b7d48 CFRunLoopRunInMode + 104
3 WebCore 0x37613a44  + 444
4 libsystem_c.dylib 0x359aa310 _pthread_start + 308
5 libsystem_c.dylib 0x359aa1d7 thread_start + 7
THREAD 8

0 libsystem_c.dylib 0x3599f8a3 start_wqthread + 7
THREAD 12

0 libsystem_c.dylib 0x3599f8a3 start_wqthread + 7
THREAD 1

0 CoreLocation 0x39148d26  + 350
1 CoreLocation 0x3917f072  + 346
2 libxpc.dylib 0x349377e8 _xpc_connection_mach_event + 772
3 libdispatch.dylib 0x35970df8 _dispatch_mach_msg_invoke$VARIANT$up + 124
4 libdispatch.dylib 0x3596095c _dispatch_queue_drain$VARIANT$up + 84
5 libdispatch.dylib 0x3597106e _dispatch_mach_invoke$VARIANT$up + 154
6 libdispatch.dylib 0x3596095c _dispatch_queue_drain$VARIANT$up + 84
7 libdispatch.dylib 0x35960894 _dispatch_queue_invoke$VARIANT$up + 36
8 libdispatch.dylib 0x3596095c _dispatch_queue_drain$VARIANT$up + 84
9 libdispatch.dylib 0x35960894 _dispatch_queue_invoke$VARIANT$up + 36
10 libdispatch.dylib 0x3596f214 _dispatch_root_queue_drain + 192
11 libdispatch.dylib 0x3596f3b8 _dispatch_worker_thread2 + 84
12 libsystem_c.dylib 0x3599fa10 _pthread_wqthread + 360
13 libsystem_c.dylib 0x3599f8a3 start_wqthread + 7
THREAD 2

0 0xffffffff 0xffffffff
THREAD 3

0 libdispatch.dylib 0x3596f258 _dispatch_root_queue_drain + 260
1 libdispatch.dylib 0x3596f3b8 _dispatch_worker_thread2 + 84
2 libsystem_c.dylib 0x3599fa10 _pthread_wqthread + 360
3 libsystem_c.dylib 0x3599f8a3 start_wqthread + 7
THREAD 6

0 CoreLocation 0x391491f0  + 136
1 CoreLocation 0x3918065c  + 36
2 CoreLocation 0x3917efee  + 214
3 libxpc.dylib 0x34930b40 do_mach_notify_port_destroyed + 160
4 libxpc.dylib 0x34930a9a _Xmach_notify_port_destroyed + 126
5 libxpc.dylib 0x34930a16 notify_server + 90
6 libxpc.dylib 0x3493789c _xpc_connection_mach_event + 952
7 libdispatch.dylib 0x35970df8 _dispatch_mach_msg_invoke$VARIANT$up + 124
8 libdispatch.dylib 0x3596095c _dispatch_queue_drain$VARIANT$up + 84
9 libdispatch.dylib 0x3597106e _dispatch_mach_invoke$VARIANT$up + 154
10 libdispatch.dylib 0x3596095c _dispatch_queue_drain$VARIANT$up + 84
11 libdispatch.dylib 0x35960894 _dispatch_queue_invoke$VARIANT$up + 36
12 libdispatch.dylib 0x3596095c _dispatch_queue_drain$VARIANT$up + 84
13 libdispatch.dylib 0x35960894 _dispatch_queue_invoke$VARIANT$up + 36
14 libdispatch.dylib 0x3596f214 _dispatch_root_queue_drain + 192
15 libdispatch.dylib 0x3596f3b8 _dispatch_worker_thread2 + 84
16 libsystem_c.dylib 0x3599fa10 _pthread_wqthread + 360
17 libsystem_c.dylib 0x3599f8a3 start_wqthread + 7
THREAD 7

0 CoreFoundation 0x33344da2 __CFRunLoopRun + 882
1 CoreFoundation 0x332b7ebc CFRunLoopRunSpecific + 356
2 CoreFoundation 0x332b7d48 CFRunLoopRunInMode + 104
3 Foundation 0x34eae78e -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 254
4 Foundation 0x34f5205c -[NSRunLoop(NSRunLoop) run] + 80
5 GPIreland 0x0012999c -[TFNetworkManager networkRunLoopThreadEntry] + 124
6 Foundation 0x34f5b67c __NSThread__main__ + 972
7 libsystem_c.dylib 0x359aa310 _pthread_start + 308
8 libsystem_c.dylib 0x359aa1d7 thread_start + 7
LOAD ADDRESS

0x0000b000

REGISTER VALUES

cpsr: 536870960
exception: 0
far: 2180846006
fsr: 7
lr: 855668917
pc: 874685872
r0: 534160688
r1: 855823900
r10: 999295808
r11: 534104888
r12: 998755496
r2: 0
r3: 534160688
r4: 2180845998
r5: 534381712
r6: 534465568
r7: 803163884
r8: 854411733
r9: 213955975
sp: 803163868
7
добавлено отредактировано
Просмотры: 1
источник
nl ja de
Вы добавляли свой.DSYM файл к testflight в разделе Crashes? Как только вы делаете это, это будет symbolicate ваши отчеты о катастрофе и давать вам лучшую информацию об этом, и возможно даже номер строки. У Testflight есть хорошие инструкции относительно того, как сделать это
добавлено автор RyanG, источник
Да, я добавил.DSYM и that' s, что testflight дает мне.
добавлено автор Dmitry Preobrazhenskiy, источник

1 ответы

EDIT: There is a fix for this bug in sdk 1.3.0-beta.2 available here: https://testflightapp.com/sdk/download/

Я работаю в TestFlight. Мы только что недавно обнаружили эту ошибку. Это - ошибка iOS с CoreTelephony. TestFlight SDK использует CoreTelephony. Таким образом, это будет иногда вызывать катастрофы. У нас есть фиксация, которая будет готовой очень скоро. Это будет включено в следующую бету (вероятно, 1.3.0-beta.2). Я очень сожалею о проблеме!

Джейсон

Больше информации о катастрофе для заинтересованных:

Есть ошибка iOS, которая заставляет случаи CTTelephonyNetworkInfo класс иногда получать уведомления после того, как они были освобождены. Вместо иллюстрирования примерами, использования и выпуска случаев необходимо вместо этого сохранить и никогда не освобождать их, чтобы работать вокруг ошибки.

10
добавлено
источник
Вы знаете, ли , CTTelephonyNetworkInfo ориентирован на многопотоковое исполнение (если не тогда единственный случай не может использоваться через нити)?
добавлено автор user102008, источник
Есть ли радар для той ошибки яблока? Это было решено с тех пор?
добавлено автор fabb, источник
фиксация теперь доступна
добавлено автор jasongregori, источник
I' m очень жаль о неудобстве!
добавлено автор jasongregori, источник
@KirbyTodd да! жаль о последнем ответе.
добавлено автор jasongregori, источник
Извините, я don' t знают. Мы всегда называли его на той же самой нити.
добавлено автор jasongregori, источник
I' m наличие подобной проблемы в моем приложении. Можно ли разделить еще некоторую деталь о том, как вы обходите эту ошибку? Это в основном просто хранит CTTelephonyNetworkInfo в статической переменной? Что-то вроде этого: статический CTTelephonyNetworkInfo *netInfo; статический dispatch_once_t dispatchToken; если (! netInfo) {dispatch_once (&dispatchToken, ^ {netInfo = [[CTTelephonyNetworkInfo alloc] init];});}
добавлено автор Kirby Todd, источник
Спасибо за то, что сообщили мне, я изо всех сил пытался довольно много найти то, что было неправильным.
добавлено автор Dmitry Preobrazhenskiy, источник