"this"포인터가 GDB 백 트레이스에서 변경되었습니다.

코어 덤프를 검사하면서 한 프레임에서 'this'포인터가 다음 프레임 (같은 스레드에서)과 다름을 알았습니다. 조금 다르지는 않지만 0x8167428에서 0x200으로 바뀌 었습니다."this"포인터가 GDB 백 트레이스에서 변경되었습니다.

나는 GDB 사용에 정통하지 않지만, 나에게 맞는 것 같지 않다. 이것이 문제가 되는가? 그렇다면 무엇이 원인 일 수 있는가?

출처

2010-03-31 Hans

문제를 재현 할 수있는 몇 가지 코드를 추가 할 수 있습니까? –

불행히도이 문제는 3 일에 한 번 발생합니다. 또한, 나는 코드의 특정 섹션 (GDB는 세마포어를 게시하는 동안 그 라인에서 포인터가 참조되지 않는다고 말했 다)을 따라 잡을 수 없었다. – Hans

같은 떨어지게가 this 포인터가 GDB 추적에서 프레임 사이 변경할 수 있습니다 볼 수에 속합니다 비록 객체가 같은 유형이라 할지라도) 이것은 특정 인스턴스를위한 것이기 때문이다. 아마도 이 아니며입니다.

0x200은 this에 유효한 값이 아니며, 일부 유형의 메모리 손상을 거의 확실하게 나타냅니다. this 포인터는 때때로 스택에 저장되어 보이지 않는 첫 번째 인수로 함수에 전달됩니다. 따라서 스택을 손상 시키면 (다른 변수에 쓰는 경계를 벗어남으로써)이 포인터가 손상된 것을 볼 수 있습니다.

값 0x200 자체가 흥미 롭습니다. 0에 매우 가깝기 때문에 실제로는 0이 아니므로,보고있는 인스턴스가 다른 객체 또는 배열의 일부일 수 있으며 그 객체/배열의 시작 부분부터 0x200 바이트에 위치하며 객체/배열의 주소는 실제로 NULL입니다. 코드를 살펴보면 어느 객체가 NULL으로 설정되어 있는지를 쉽게 알아낼 수 있어야합니다. 이렇게하면 0x200이보고됩니다.

출처

2010-03-31 22:42:51 SoapBox

따라서 0x200은 십진수로 512입니다. 이것은 512 바이트 크기의 객체를 검색해야한다는 것을 의미합니까? – Hans

정확하지 않습니다. 이것은 처음부터 512 오프셋에 있기 때문에 적어도 512 바이트를 포함하는 객체를 찾고 있습니다. 또한 배열 일 수도 있습니다 ... "this"가 128 바이트이면이 객체의 배열에서 네 번째 인덱스 (다섯 번째 요소)입니다. 아니면 둘의 조합 일 수도 있습니다. 그러나 어딘가의 어떤 것은 null입니다. – SoapBox

이 답변은 충분히 가깝습니다. 'this'포인터가 바뀐 클래스에 가까운 버퍼가 있었고 그 포인터는 제로가되었습니다. – Hans

코드의 최적화로 인해 디버거가 혼동을 일으킬 수 있습니다. 이는 소매 코드를 디버깅 할 때 자주 발생하는 문제입니다. 최적화를 비활성화하고 시나리오를 다시 실행하고 동일한 문제가 발생하는지 확인하십시오.

출처

2010-03-31 22:36:49 JaredPar

죄송 합니다만, 해당 지역의 코드는 최적화되어 있지 않습니다. – Hans

@Hans, 사용자 최적화가 아니라 컴파일러 최적화를 의미했습니다. 모든 컴파일러 최적화를 비활성화 하시겠습니까? – JaredPar

미안하지만, 그게 내가 의미하는 바 였어. -O2 – Hans

this 포인터가 프레임에 국한됩니다.

는 다른 프레임은 다음 프레임의 함수가 (다른 개체에서 호출되는 경우 'C'기능, 당신을 0x200

출처

2010-03-31 22:37:27 osgx

으로 컴파일 된 다른 공유 객체가 사용됩니다. 두 프레임은 같은 클래스의 함수입니다. – Hans

"this"포인터가 GDB 백 트레이스에서 변경되었습니다.

답변

관련 문제