"죽음의 구문 분석 오류"주위에 어떤 방법이 있습니까?

Question

매우 중첩 된 시나리오 (예 : 매우 작은 인스턴스가있는 다른 객체 인스턴스를 참조하는 다른 객체 인스턴스를 참조하는 객체 인스턴스)에 PHP의 간단한 구문 분석 오류가 있음을 알았을뿐만 아니라 구문 분석 오류를 모두 자동으로로드되는) 구문 분석 오류를보고 대신 일반적으로 할 것이 실행을 중단 PHP 멈추게 할 수 있습니다 -이 여러 번 및 매우 다른 코드를 기지, 항상 적절한 error_reporting 함께 본 적이 설정 집합.

주위에 경로가 있습니까? 즉, 구문 분석 오류 보고서를 어떻게 든 표시해야 할 수 있습니까?

레코드의 경우이 동작이 여러 번 디버깅되었으므로 PHP가 구문 분석 오류를 올바르게 처리하지 못해 이러한 중단이 발생했음을 100 % 확신합니다. 내가 이런 질문을하는 이유는 기본적으로 어둠 속에 남아 있기 때문입니다. PHP가 재미 있느냐, 아니면 어딘가에 코드에 오작동하는 루프가 있는지 여부를 알 수 없기 때문에 디버깅에 시간이 걸립니다. PHP가 구문 분석 오류를보고해야한다면 저장해야합니다.

Answer 1

범인은 문자 그대로으로 밝혀졌으며, 설명서는 사용 중지 상태로 유지하는 것이 좋습니다. 특정 오류는 단순히 콜렉션 스택 추적의 인수에 매우 많은 양의 데이터를 생성하는 것이 었습니다. collect_params가 4로 설정된 xdebug를 고갈시키고 xdebug를 작성하고 확장 PHP를 사용하여 PHP를 정지 시켰습니다. 실제로는 절대로 사용자 정의 예외 핸들러를 사용하지 않았지만 xdebug에서 스택 추적을 검색하지만 분명히 xdebug는이 데이터를 수집합니다.

a) 복제하기가 쉽지 않음 b) xdebug로 프로파일 링하는 것이 도움이되지 않음 c) xdebug + dbgp로 코드를 단계별로 실행하지 못함 d) 거의 추적 할 수 없음 (아무런 의도도 없음)가 이 아닌 경우가 종종 있었음 PHP 오류 로그 파일에 오류를 기록하고 e) 예외 처리 프로세스에 관여하지 않았기 때문에 사용자 정의 예외 처리기로 xdebug가 의심스럽지 않았습니다. 그래서 나는 생각했다.

그래서 죽음의 구문 분석 오류 같은 건 없으며, 그것은 내 잘못이 아니라고 결코 추측하지 못하는 것을 배웠습니다. 희망적으로이 응답은 앞으로 다른 사람들에게 도움이되기를 바랍니다.

Answer 2

의견에서 부분적으로 언급 한 것처럼 error_reporting(E_ALL)은 모든 오류를 표시하는 데 도움이 될 수 있습니다. ini_set을 사용하고 display_errors의 값을 on으로 설정해야 할 수도 있습니다.

개인적으로 귀하의 질문이 명확하지 않으며 서식을 개선하고 이해하기 쉬워야한다고 생각합니다.

업데이트 : 코드를 실행중인 서버/컴퓨터가 매우 느린 것 같습니다. '매달리기'가 실제로 일어나지 않아야합니다. 아니면 자세히 설명해 주시겠습니까?

또한 무한 루프 나 거의 무한 루프에서 멈출 수 있습니다. 모든 코드를 게시하지 않으면 이것이 우리가 당신을 도울 수있는 한계이기 때문에 코드를 자세히 확인하십시오.

업데이트 2 : 호출하려고 할 때 개체의 이름을 잘못 입력 한 것 같습니다. 그렇지 않으면 개체를 올바르게 선언하지 않았을 수 있습니다.

가능성이 가장 높습니다.