Get/SetILFunctionBody apparently worked well in the Rotor Beta releases, but it got
broken in the final Rotor release with the problem you have described.
A quick patch for the problem is to apply the following modifications to
PEFile::RVAToPointer in sscli\clr\src\vm\pefile.cpp (the 3 new lines are marked with
***):
BYTE *PEFile::RVAToPointer(DWORD rva)
{
if (rva == 0)
return NULL;
if(m_hCorModule) {
DWORD types = CorMap::ImageType(m_hCorModule);
if(types == CorLoadOSMap || types == CorLoadDataMap || types ==
CorLoadOSImage)
{
*** DWORD t = rva;
rva = Cor_RtlImageRvaToOffset(m_pNT, rva, GetUnmappedFileLength());
*** if (rva == 0)
*** rva = t;
}
}
return m_base + rva;
}
This is just a workaround for the problem that can cause undesired behavior under some
circumstances. The clean fix would involve more complex changes in several files - I
can put it together if there is interest in it.
-Jan
This posting is provided "AS IS" with no warranties, and confers no rights.
-----Original Message-----
From: Nam Tran [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 13, 2003 4:21 PM
To: [EMAIL PROTECTED]
Subject: Re: [DOTNET-ROTOR] Problems with profiling
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
>
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
