I'm using the Rotor release of 01 Nov 2002. That's the final release, correct?
The problem with replacing the method body is exactly as Fabian described, i.e. the module has image type CorLoadOSMap, CorLoadOSImage, or CorLoadDataMap, resulting in BAD_FORMAT_ASSERT(header.Code != 0). Note that with the sample "read-only" profiler, some event masks cause havoc, too. It'd be great if someone who has successfully used SetILFunctionBody in Rotor tells us of their experience. Nam Jan Kotas wrote: > > 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 >
