성태의 닷넷 이야기
홈 주인
모아 놓은 자료
프로그래밍
질문/답변
사용자 관리
사용자
메뉴
아티클
외부 아티클
유용한 코드
온라인 기능
MathJax 입력기
최근 덧글
[정성태] Java - How to use the Foreign Funct...
[정성태] 제가 큰 실수를 했군요. ^^; Delegate를 통한 Bein...
[정성태] Working with Rust Libraries from C#...
[정성태] Detecting blocking calls using asyn...
[정성태] 아쉽게도, 커뮤니티는 아니고 개인 블로그입니다. ^^
[정성태] 질문이 잘 이해가 안 됩니다. 우선, 해당 소스코드에서 ILis...
[양승조
] var대신 dinamic으로 선언해서 해결은 했습니다. 맞는 해...
[양승조
] 또 막혔습니다. ㅠㅠ var list = props[i].Ge...
[양승조
] 아. 감사합니다. 어제는 안됐던것 같은데....정신을 차려야겠네...
[정성태] "props[i].GetValue(props[i])" 코드에서 ...
글쓰기
제목
이름
암호
전자우편
HTML
홈페이지
유형
제니퍼 .NET
닷넷
COM 개체 관련
스크립트
VC++
VS.NET IDE
Windows
Team Foundation Server
디버깅 기술
오류 유형
개발 환경 구성
웹
기타
Linux
Java
DDK
Math
Phone
Graphics
사물인터넷
부모글 보이기/감추기
내용
<div style='display: inline'> <h1 style='font-family: Malgun Gothic, Consolas; font-size: 20pt; color: #006699; text-align: center; font-weight: bold'>닷넷 프로파일러의 오류 코드 - 0x80131363</h1> <p> CORPROF_E_UNSUPPORTED_CALL_SEQUENCE (0x80131363) 오류에 대한 좀 더 상세한 정보가 있어서 소개합니다. ^^<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > Why we have CORPROF_E_UNSUPPORTED_CALL_SEQUENCE ; <a target='tab' href='https://blogs.msdn.microsoft.com/davbr/2008/12/23/why-we-have-corprof_e_unsupported_call_sequence/'>https://blogs.msdn.microsoft.com/davbr/2008/12/23/why-we-have-corprof_e_unsupported_call_sequence/</a> </pre> <br /> 정리해 보면, 0x80131363 오류는 CLR 2.0부터 반환하도록 추가되었습니다. 이전에도 언급했지만,<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > 닷넷 프로파일러의 오류 코드 정보 ; <a target='tab' href='http://www.sysnet.pe.kr/2/0/10880'>http://www.sysnet.pe.kr/2/0/10880</a> </pre> <br /> 0x80131363 오류는 ICorProfilerInfo 관련 메서드를 호출할 때 응용 프로그램이 불안정한 상태로 빠질 경우에 해당하면 반환됩니다. 이 오류는 주로 "hijacking profiler"에서 볼 수 있다고 합니다. (하지만, non-hijacking profiler에서도 발생할 수 있음.) hijacking profiler란? 프로파일러 관련 코드에 진입하기 위해 임의의 시점에 스레드의 레지스터 컨텍스트를 강제로 재설정하거나, 보통 그렇게 진입한 프로파일링 코드에서 ICorProfilerInfo를 이용해 CLR 내부로 재진입하는 종류의 프로파일러입니다.<br /> <br /> 왜 이것이 문제가 되냐면? 프로파일러가 스레드를 제어하기 시작했을 때 하필 CLR 내부의 자료 구조에 대한 lock을 소유할 경우도 있는데, 이 스레드에서 CLR 내부로 다시 재진입을 하게 되면 또 다른 lock을 가지는 것도 가능하게 되고 결국 deadlock이나 AV(Access Violation)에 쉽게 빠질 수 있다는 것입니다.<br /> <br /> CLR 1.x까지는, 위와 같은 상황이 발생하면 '운에 따라' ICorProfilerInfo가 잘 호출될 수도 있고, 또는 deadlock/AV가 발생할 수도 있었지만 CLR 2.0부터는 아예 0x80131363을 반환해서 그런 상황을 미연에 방지하도록 합니다.<br /> <br /> 일반적으로 ICorProfilerCallback으로 호출되는 메서드 내에서 실행되는 코드로 이뤄진 non-hijacking profiler라면 ICorProfilerInfo 메서드를 호출하는 것은 문제가 없습니다. 예를 들어, ICorProfilerCallback::ClassLoadFinished 콜백 함수 내에서 클래스에 대한 정보를 요청하는 것은 괜찮습니다. 사실 이 시점에 클래스 정보가 완전하지 않아서 구할 수 없는 경우도 있는데 그럼 CORPROF_E_DATAINCOMPLETE를 반환할 뿐 deadlock이나 AV 오류가 발생할 염려는 없습니다. 이런 식으로 안전하게 ICorProfilerInfo를 호출하는 것을 "동기화(synchronous)"되었다고 합니다. 즉, ICorProfilerCallback 콜백 함수 내에서 호출되는 모든 유형은 synchronous에 해당하기 때문에 안전합니다.<br /> <br /> 반면, ICorProfilerCallback 콜백 함수가 아닌, 관리 스레드 상에서 ICorProfilerInfo가 제공하는 메서드를 호출하면 이를 "비동기화(asynchronous)"되었다고 합니다. 이러한 asynchronous 유형의 호출은 위험하며 CLR 2.0이후부터는 무조건 0x80131363 오류를 반환합니다.<br /> <br /> asynchronous 상황에서 ICorProfilerInfo에서 제공하는 메서드들이 대체로 위험하긴 하지만, 다음의 메서드들은 허용된다고 합니다.<br /> <br /> <ul> <li>GetEventMask/SetEventMask</li> <li>GetCurrentThreadID </li> <li>GetThreadContext </li> <li>GetThreadAppDomain </li> <li>GetFunctionFromIP </li> <li>GetFunctionInfo/GetFunctionInfo2 </li> <li>GetCodeInfo/GetCodeInfo2 </li> <li>GetModuleInfo </li> <li>GetClassIDInfo/GetClassIDInfo2 </li> <li>IsArrayClass </li> <li>SetFunctionIDMapper </li> <li>DoStackSnapshot </li> </ul> <br /> 그 외에 알아둘 점은?<br /> <br /> <ol> <li>fast-path 방식의 Enter/Leave 콜백 내에서 ICorProfilerInfo 호출은 asynchronous로 간주합니다. (fast-path인지 slow-path인지에 대해서는 "<a target='tab' href='https://blogs.msdn.microsoft.com/davbr/2007/03/22/enter-leave-tailcall-hooks-part-1-the-basics/'>https://blogs.msdn.microsoft.com/davbr/2007/03/22/enter-leave-tailcall-hooks-part-1-the-basics/</a>" 글을 참조) 반면 slow-path 방식의 Enter/Leave 콜백 내에서는 synchronous로 간주.</li> <li>가로채기 된 메서드 내에서 ICorProfilerInfo 호출은 asynchronous로 간주. (예를 들어, 프로파일러가 정의한 함수를 호출하도록 IL 코드를 변경해서 호출되는 경우가 있다면, 프로파일러가 제공한 함수 내에서 ICorProfilerInfo의 함수를 호출하면 안 됨)</li> <li>FunctionIDMapper 후킹 코드 내에서 ICorProfilerInfo 호출하는 것은 asynchronous로 간주.</li> <li>프로파일러 모듈이 직접 만든 스레드가 ICorProfilerInfo를 호출하는 것은 안전하게 synchronous로 간주. 왜냐하면, 그 스레드 상에서 CLR 내부로 재진입하는 등의 작업은 아무런 충돌 위험이 없기 때문.</li> <li>DoStackSnapshot을 호출한 상황이 synchronous였다면, 그것의 StackSnapshotCallback 콜백 함수 내에서의 ICorProfilerInfo 호출은 안전하게 synchronous로 간주.</li> </ol> </p><br /> <br /> <br /><hr /><span style='color: Maroon'>[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]</span> </div>
첨부파일
스팸 방지용 인증 번호
6840
(왼쪽의 숫자를 입력해야 합니다.)