Since your JIT_Checkpoint is probably a helper call you should be using HCIMPL0 macro to implement it.
There are a several differences between helper calls and fcalls: - Fcalls are implemented using FCIMPLXXX/FCIMPLEND macros. They are hooked through the tables in vm/ecall.cpp. They have a matching extern method in the C# implementation of BCL marked with [MethodImplAttribute(MethodImplOptions.InternalCall)]. They are visible to the user, i.e. they show up in the stacktrace. - Helper calls are implemented using HCIMPLXXX/HCIMPLEND macros. They are hooked through table in jitinterface.cpp. They are fully internal to the JIT. They are not visible to the user, i.e. they do not show up in the stacktrace. In your case, the crash may be caused by stackwalk failing to find the matching entry for your helper call in the BCL because of the FCIMPL vs. HCIMPL mismatch. Also, make sure that you do LABELSTACK before calling your helper in the FJIT macro. This is another crucial part to make the GC work while you are in the debugger code. LABELSTACK records the locations of the object references in the evaluation stack for the GC. If none of this helps, can you please post more data (full stack trace, values of important variables) about the crash you are seeing? -Jan This posting is provided "AS IS" with no warranties, and confers no rights. -----Original Message----- From: Evgeny Vigdorchik [mailto:ven@;TEPKOM.RU] Sent: Thursday, November 14, 2002 8:38 AM To: [EMAIL PROTECTED] Subject: [DOTNET-ROTOR] GC in exception handler Hi, There is the following problem in our debugger and we can't figure out its exact reason: We have the following helper called from JITted code (it may be inserted at any point in the IL stream) : FCIMPL0(void, JIT_Checkpoint) { THROWSCOMPLUSEXCEPTION(); HELPER_METHOD_FRAME_BEGIN_0(); DebuggerExitFrame __def; g_pDebugInterface->SendCheckpoint(GetThread()); __def.Pop(); HELPER_METHOD_FRAME_END(); } HCIMPLEND The SendCheckpoint () function is actually SendUserBreakpoint () sending the instance of the class DebuggerCheckpoint : public DebuggerUserBreakpoint. The problem arises when we need to make a gc in DebuggerCheckpoint::TriggerPatch, eventually we get access violation in the scanroots stackwalk. Is it illegal to do GC in the handler or it is something else? Any help welcome. Evgeny Vigdorchik St.Petersburg State University Institute of Information Systems