런타임 환경에서 무한 루프를 감지 할 수 있습니까?

런타임 환경에서 무한 루프를 감지 한 후 관련 프로세스를 중지 할 수 있습니까? 아니면 그러한 논리를 구현하는 것이 중지 문제를 해결하는 것과 동일합니까?

이 질문의 목적을 위해, "무한 루프"를 정의하여 일련의 명령어와 관련 시작 스택 / 힙 데이터를 의미하며, 실행시 프로세스를 이전과 정확히 동일한 상태 (데이터 포함)로 반환합니다. 무한 루프를 시작합니다. 다시 말해, pi의 무한 길이의 십진 확장을 생성하는 프로그램은 "무한 루프"에서 "고정되지"않습니다. 매번 반복 할 때마다 연관된 메모리의 어딘가에 더 많은 pi 자리수가 있기 때문입니다.

( /programming//q/16250472/1858225 에서 포팅 )

이론적 으로 런타임 환경에서 다음 절차를 사용하여 이러한 루프를 점검 할 수 있습니다 .

명령이 실행 된 후 런타임 환경은 실행중인 프로세스 상태 (예 : 레지스터, PC, 스택, 힙 및 전역을 포함하여 이와 관련된 모든 메모리)의 완전한 이미지를 만들고 해당 이미지를 어딘가에 저장 한 다음 확인 해당 프로세스에 대해 이전에 저장된 이미지와 일치하는지 확인하십시오. 일치하는 경우 프로세스가 무한 루프에 멈 춥니 다. 그렇지 않으면 다음 명령이 실행되고 프로세스가 반복됩니다.

실제로, 모든 단일 명령 후에이 점검을 수행하는 대신 런타임 환경은 프로세스를 주기적으로 일시 정지하고 저장 상태를 만들 수 있습니다. 프로세스가 n 개의 상태를 포함하는 무한 루프에 걸리면 최대 n 개의 검사 후에 중복 상태가 관찰됩니다.

물론 이것은 정지 문제에 대한 해결책 이 아닙니다 . 차이점은 여기에서 설명 합니다 .

그러나 그러한 특징은 막대한 자원 낭비 일 것이다 . 프로세스 와 관련된 모든 메모리 를 저장하기 위해 프로세스를 계속 일시 중지하면 엄청나게 느려지고 엄청난 양의 메모리가 매우 빨리 소모됩니다. (오래된 이미지는 잠시 후에 삭제 될 수 있지만, 너무 무한한 경우 큰 무한 루프 (예 : 상태가 많은 루프)로 인해 저장 될 수있는 총 이미지 수를 제한하는 것은 위험합니다. 또한,이 기능은 오류를 포착하는 기능이 매우 제한적이며 다른 디버깅 방법으로 무한 루프를 찾는 것이 비교적 간단하기 때문에 (실제로 코드를 단계별로 실행하는 것과 같이) 비교적 많은 이점을 제공하지 않습니다. 논리 오류를 인식).

따라서 누군가가 단지 차기 위해 프로그래밍하지 않는 한 그러한 런타임 환경이 존재하거나 존재한다는 것을 의심합니다. (나는 지금하고 싶은 유혹을 받는다.)

프로그램이 외부 세계와 상호 작용하지 않는다고 가정하면 프로그램의 전체 상태를 캡슐화하는 것이 실제로 가능합니다. (이것은 적어도 입력을 수행하지 않는다는 것을 의미합니다.) 또한 프로그램이 일부 결정적 환경에서 실행 중이므로 각 상태에 고유 한 후속 작업이 있다고 가정하여 런타임이 스레드되지 않았거나 스레딩을 의미합니다 결정적으로 시퀀스로 줄일 수 있습니다.

이처럼 불가능하지만 이론적으로는 제한이없는 가정 하에서 프로그램을 복제하여 두 개의 별도 런타임에서 실행할 수 있습니다. 각각 정확히 동일한 계산을 수행합니다.

그렇게하겠습니다. Tortoise 런타임에서 한 번 실행하고 동시에 Hare 런타임에서 실행합니다. 그러나 Hare 런타임이 정확히 두 배 빠른 속도로 작동하도록 준비 할 것입니다. Tortoise 런타임이 한 단계를 만들 때마다 Hare 런타임은 두 단계를 수행합니다.

$n$$p$$kn$$k$$kn\ge p$

테스트의 총 비용은 단계 당 하나의 추가 상태와 하나의 상태 비교이며 프로그램이 첫 번째 루프를 완료하는 데 걸리는 단계 수의 3 배 이상 종료됩니다. (거북에서는 1 회, 토끼에서는 2 회, 총 3 회)

내가 사용한 용어에서 알 수 있듯이 이것은 Robert Floyd의 유명한 Tortoise and Hare cycle-detection 알고리즘입니다.

Floyd의 사이클 감지 알고리즘을 제안하려고했던 것처럼 rici의 포스트가 저를 이겼습니다. 그러나 전체 상태의 비교 속도를 높이면 전체를보다 실용적으로 만들 수 있습니다.

제안 된 알고리즘의 병목 현상은 전체 상태를 비교하는 것입니다. 이러한 비교는 일반적으로 끝나지 않지만 첫 번째 차이에서 일찍 중지됩니다. 한 가지 최적화는 과거의 차이가 발생한 위치를 기억하고 상태의 해당 부분을 먼저 확인하는 것입니다. 예를 들어, 위치 목록을 유지 관리하고이 목록을 검토 한 후 전체 비교를 수행하십시오. 이 목록의 위치에 차이가 있으면 비교를 중지하고 (실패한 경우) 위치를 목록의 맨 앞으로 이동하십시오.

다른 (확장 가능한 확장 가능) 접근 방식은 증분 해싱을 사용하는 것입니다. 상태의 일부가 변경 될 때 해시 값을 O (1)에서 쉽게 조정할 수 있도록 전체 상태의 함수를 선택하십시오. 예를 들어, 가중 합계 상태 단어 mod 일부 큰 소수를 취하고 비가 중 합계 mod 일부 다른 큰 소수를 연결하십시오 (또한 다른 가중 및 모듈러스를 갖는 모듈화 된 가중치 제곱 단어의 합을 던질 수 있음). 이런 식으로 해시 업데이트는 각 실행 단계에서 O (1) 시간이 걸리고 적중을 얻을 때까지 비교에는 O (1) 시간이 걸립니다. 오 탐지 확률 (즉, 상태가 다른 동안 해시 일치)은 매우 낮으며, 이러한 상황이 발생하더라도 많은 수의 참 네거티브에 대해 상각됩니다 (거짓 네거티브는 불가능합니다).

물론 실제로는 숫자 pi의 숫자 생성과 같은 상황에 처할 가능성이 더 높습니다. 또 다른 빈번한 가능성은 무한 루프가 메모리를 할당하는 것이며,이 경우 사용 가능한 모든 메모리를 빠르게 소모합니다.

알고리즘과 데이터 구조에 대한 과정에서 오토 그라 더는 때때로 무한 루프에 빠지는 학생 제출물을 처리해야합니다. 이 작업은 30 초 시간 초과 및 특정 메모리 제한으로 처리됩니다. 둘 다 우리가 등급의 일부로 부과하는 런타임 및 메모리 예산보다 훨씬 느슨합니다. 이러한 컨텍스트에서 진정한 무한 루프 감지를 구현하면 상당히 느리게 실행될 수 있기 때문에 확실하지 않습니다 (상태 해싱에 대한 하드웨어 지원이 도움이 될 수 있지만 다시 추가 용도가 필요합니다) 이것을 정당화하십시오). 학생들이 프로그램 시간이 초과되었음을 알면 대개 무한 루프를 찾을 수 있습니다.

AProVE의 종단 툴 행하고있다 (하스켈 프로그램의 서브 클래스 포함) 재기록 시스템에서 정적 분석 증명 종료되지 않는 프로그램의 실제 예를주는 비 종료. 이 기법은 매우 강력하며 협소 한 기법의 변형을 사용하여 작동합니다 .

내가 아는 한, 일반 언어에 대한 실제 비 종료를 감지하는 작업은 많지 않았습니다.