Cocoa/Mac : JavaScript 38 번째 호출에서 코어 크래시가 발생했습니다.

Question

JavaScript 라이브러리 (긴 텍스트로 은가되어야 함)를 사용해야하는 Mac OSX (10.8) 용 Cocoa 앱을 개발 중입니다.

데모 애플리케이션에서 모든 것이 잘된 것처럼 보였지만 프로젝트에 코드를 통합하는 동안 문제없이 37 번만 호출 한 다음 38 번째 시간을 충돌 할 수 있습니다.

JS 코드를 호출하기 위해 Apple의 JSWrappers.m (JavaScriptCoreHeadStart 예제)을 사용하고 있습니다. 위에서 언급 한 바와 같이, 그것은 상관없이 입력이 무엇이라고하지 않습니다 38 시간 -callStringJSFunction:withParameters:에 충돌

JSObjectCallAsFunction(self.jsContext, jsFunction, NULL, argumentCount, arguments, NULL); 

(이것은 모든 입력 문자열로 충돌하고, (A EXC_BAD_ACCESS와) 충돌 선은 # 149입니다 37 개의 이전 반복에서 사용되는 경우 동일한 문자열이 작동 함). EXC_BAD_ACCESS는 입력 변수에 의해 액세스되지 않으므로 (예 : 해당 행 바로 앞에 self.jsContext이 호출 됨) 작동합니다. 즉, 충돌을 일으키는 함수 호출 자체입니다.

우리는이 문제의 원인에 대해 잘 모르고 더 많은 디버깅 방법을 모릅니다. 누구도 힌트를 가지고 있습니까? 감사합니다. .

// EDIT

나 자신을 수정해야합니다 : 그것은 너무 "데모 애플리케이션"에서 작동하지 않습니다. 우리는 함수가 호출 될 때마다 JSWrappers 개체를 다시 만들기 (새로운 JSGlobalContext) 경우에도이 경우, 코드는 우리가 전화를 38 시간을 충돌 -callStringJSFunction:withParameters:

// EDIT2

, 그것은 충돌하지 않습니다 더 이상. 그러나 이로 인해 코드가 훨씬 느려집니다 (JS 인터프리터가 매번 스크립트를 읽어야하므로 당연한 결과입니다.

는 // EDIT3는

또 다른 발견 : 32 비트에서 응용 프로그램을 구축하는 코드 충돌한다. 대신 64 비트로 작성하면 완벽하게 작동합니다. JS 코드는 언제든지 문제없이 실행됩니다. 이것은 이상합니다. JavaScript 코어 프레임 워크 자체의 버그 일 수 있습니까?

Answer 1

내 질문에 답해주세요.

분명히 JavaScript 코어의 버그 (?)입니다. 32 비트 바이너리의 경우 몇 가지 이유로 37 회 이상 함수를 호출 할 수 없습니다 (메모리 문제?). 이러한 문제는 64 비트 바이너리에는 나타나지 않습니다.

이 문제는 OSX 10.8.4에서 발생합니다.

Answer 2

오늘은 다소 오래된 스레드이지만 다소 관련이 있습니다.
Google은 여전히 ​​iOS 8.2를 지원하고 있으며,이 문제는 수많은 iOS 8.4 사용자와 관련이있는 것으로 나타났습니다. 일부 연구 결과에 따르면 이번에는 iOS 버전의 버그 인 것으로 나타났습니다.

합성 테스트에서 다중 스레드 (100 회 루프의 새 스레드)에서 동일한 -callWithArguments:@[] 함수를 호출했습니다. 이것은 대부분의 테스트 장치에서 완료되며, 32 비트 iPod touch에서도 iOS 9.x를 실행합니다 . 공통 분모는 iPhone 5S (64 비트, 1GB RAM)에서도 iOS 8.x였습니다. WTFCrash가 발생했습니다.

우리의 프로덕션 응용 프로그램에서는 응용 프로그램이 callWithArguments을 비동기로 호출하고 경우에 따라 여러 스레드에서 동시에 호출합니다. 여러 스레드가 동시에 장기 실행 기능을 호출하여 문제를 일으킨 것으로 보입니다. 다음이를 중지하려면, 나는이이 처리 듯 여러 아키텍처와 함께 모든 테스트 아이폰 OS 버전 (8.4, 9.x의, 10.3)에 충돌을 중지

@synchronized (<#token#>) { 
     <#statements#> 
    } 

에 callWithArguments을 감쌌다. 이 호출은 백그라운드 스레드에서 수행되었으므로 UI에는 아무런 영향을 미치지 않습니다.

이 방법이 가장 효과적인 방법이나 해결책은 아니지만 매일 수십 명의 사용자가 일시적인 충돌을 겪고있는 지금 문제가 해결 된 것으로 보입니다. 그렇게 말하면서, 누구든지이 일을하는 더 좋은 방법을 알고 있다면 알려주십시오.

TL; 같은 함수를 호출 박사
다중 스레드는 WTFCrash 함께 폭탄을 일으켰습니다. @synchronized 자물쇠에있는 전화를 감쌌다.