Przesyłamy aplikację od 10,6 do 10,8. Patrzę na dylib, który ładujemy w aplikacji. Mam do czynienia z bardzo niezwykłą awarią w Garbage Collection Work Queue z następującym komunikatem.Awaria kolejki zadań usuwania śmieci, jeśli dylib jest załadowany
malloc: Thread::suspend(): unable to suspend a thread: err = 268435459, Thread 0x111000000: _pthread = 0x108129000, _thread = 0x8b07, _stack_base = 0x108129000, enlivening on, 0 local blocks
Dla aplikacji GCC_ENABLE_OBJC_GC = required
jest ustawiona. Jeśli mam GCC_ENABLE_OBJC_GC = required
w dylib, nadal będzie się on zawieszał. Nie mogę wyłączyć narzędzia do zbierania śmieci w aplikacji. Muszę sobie poradzić z moim upadkiem.
Przyczyną wypadku okazuje się, że śmieciarz nie jest w stanie zawiesić wątku. (jak mówi w dzienniku). Ten wątek jest tworzony przy użyciu thread_create(). Jeśli wstawię nieskończoną pętlę while (ze snem) w konstruktorze dylib, to nie ulegnę awarii. Występuje awaria po zakończeniu wykonywania przez konstruktora.
Czy jest to sposób, aby powiedzieć śmieciarzowi, aby nie próbował zawiesić wątku? Lub zwiększyć liczbę odnośników wątku? lub cokolwiek, co mogę zrobić, aby zatrzymać zbieracz śmieci, aby nie zakłócać mojego kodu dyliblowego.
Czy możesz wyjaśnić: czy zamierzasz używać swojego GC w projekcie? albo nie? Moim pierwszym przypuszczeniem jest to, że cecha, którą ładujesz została zbudowana, aby używać GC, ale twoja główna aplikacja nie była. – ipmcc
Po prostu piszę dylib i ładowanie dylib powoduje awarię. Aplikacja została zbudowana, aby używać GC (GCC_ENABLE_OBJC_CC = wymagany). Jeśli włączę lub wyłączyłem flagę na dylib, nie ma to znaczenia. Wciąż się psuje. – MacGeek
jakiego kompilatora używasz dla tych dwóch? Wersja gcc? Ponadto: jakie są cele wdrażania, podstawowe sdks? –