We have done a lot of bug fixes for the final release. I remember some of those had to do with CorLoadOSMap, CorLoadOSImage. Try to download the final release and reproduce the problem with it.
We haven't done a lot of comprehensive testing of profiling interfaces in Rotor, so there may be bugs. But I have heard people are able to successfully use SetILFunctionBody in Rotor. -Jan This posting is provided "AS IS" with no warranties, and confers no rights. -----Original Message----- From: Schmied Fabian [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 1:44 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET-ROTOR] Problems with profiling Nam, I had the same problem: Allocating a method body with the allocator yielded a memory block which did not fit into the file sections specified in the module headers. Unfortunately, I could not solve the problem, so if anybody out there knows what the problem is here, please tell us. Fabian PS: The problem in my case is the following (speaking of CLR 1.0 and SSCLI 1.0, release 2): The memory allocated using the IMethodMalloc has of course an RVA which is not part of any of the module's sections, as the are specified in the module's file header. However, if a module has the image type CorLoadOSMap, CorLoadOSImage, or CorLoadDataMap (whose meaning I don't know at all), PEFile::RVAToPointer delegates to Cor_RtlImageRvaToOffset, which finally results in calling Cor_RtlImageRvaToSection32. This iterates through the PEFile's sections, looking where the RVA fits in and calculating the code pointer accordingly. Since the RVA doesn't fit in any of the sections, it returns 0, the code pointer is wrongly calculated and a BAD_FORMAT_ASSERT(header.Code != 0) fires. However, different than in your case, I found that it didn't work with the CLR either (which threw a BadFormatException, I think). Only if the image type of the module was CorLoadImageMap, or if I manually skipped Cor_RtlImageRvaToOffset using the debugger, it would run correctly. -----Ursprüngliche Nachricht----- Von: Nam Tran [mailto:[EMAIL PROTECTED]] Gesendet: Do 13.02.2003 04:10 An: [EMAIL PROTECTED] Cc: Betreff: [DOTNET-ROTOR] Problems with profiling I've run into problems with Rotor's profiling interface while trying some simple things, initially just replacing body of a tiny method with an exact copy. I base my code on the sample profiler. I try the same thing with the CLR and things work fine there. Here are the problems: - Some event mask combinations cause problem in Rotor (with just the straight sample profiler, none of my changes yet) + DN_PROFILER_MASK=0x20 causes a System.StackOverflowException somewhere in closing down the EE + DN_PROFILER_MASK=0x4f/0x8f cause an assertion failure at line 401 in binder.cpp while the EE is trying to run some class finalisation + 0x40 and 0x80 work ok, I haven't tried others - With my changes to replace the body of a tiny method with an exact copy as so: In JITComplicationStarted, if it's ok to block the EE, GetILFunctionBody If it's tiny GetILFunctionBodyAllocator Allocate buffer with given size Copy body to new buffer SetILFunctionBody Done. + This change works fine for the CLR + In Rotor, the new body is never picked up while the new RVA is properly set for both the metadata and the in memory MethodDesc*. Tracing it in the debugger, I found that the new RVA, being after the module, is out of range when checked against the values in the file headers. This result in Module::GetILCode(rva) returning the base of the file. Part of stack trace: sscoree.dll!Cor_RtlImageRvaToSection32(...) Line 78 sscoree.dll!Cor_RtlImageRvaToSection(...) Line 110 sscoree.dll!Cor_RtlImageRvaToOffset(...) Line 203 sscoree.dll!PEFile::RVAToPointer(...) Line 110 sscoree.dll!Module::ResolveILRVA(...) Line 540 sscoree.dll!Module::GetILCode(...) Line 1760 The module (after replacing a method's body) is not 'InMemory', I haven't come across the path where the module is an InMemoryModule yet. Can anyone tell what I'm doing wrong and/or what else is wrong? Thanks, Nam
