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
