dotnet clr: Hi,

ECMA states in Section 1.8.1.4 (Partition III) on Class and Object
Initialization Rules:

"An object constructor shall not return unless a constructor for the base
class or a different construct for the object's class has been called on the
newly constructed object. The verification algorithm shall treat the this
pointer as uninitialized unless the base class constructor has been called."

This means in particular that, if a .ctor didn't invoke a base class .ctor
but another .ctor of the same class, then the "this" pointer is not
initialized. For example, class A has 2 .ctors that invoke eachother:
recursive constructor invocation is allowed at the bytecode level!

BUT, the examples I tried show that the "this" pointer is initialized even
after invoking another .ctor of the same class - for example I can load the
"this" into a local variable.

SO, it seems to me that the "this" is considered initialized also after
invoking a ctor of the same class and NOT ONLY a ctor of the base class!

====================================

There is another issue which is not clear.

Looking in the ROTOR source, I found the following commented idea:

"If there are any locals (or arg slot 0) containing uninit vars, it is
illegal to be in a try block."

This corresponds to error "VER_E_THIS_UNINIT_EXCEP" "Uninitialized this on
entering a try block"

Beside the fact that this is not documented in ECMA, I cannot have it
confirmed by examples.

Is this verification error still checked in the current version of the
verifier?

Many thanks for any help!

[quoted text, click to view]

ALl that says is that the "verification algorithm shall treat the this
pointer as uninitialized", it does not say that the variable will *be*
uninitialized. What these means is that during verification the verifier
should look at the constructor, see it doesn't call the base, and treat this
as an uninitialized variable. It doesn't mean that the variable will be null
when a base constructor is not called.

I suspect your examples are valid but unverifiable, try running peverify on
your examples and see what it has to say.

Hi Daniel,

[quoted text, click to view]

I've completely understood that this is a verification issue - see also the
end of my previous post:

"What I'm complaining about is a verification rule not correctly specified in
the ECMA Standard."

[quoted text, click to view]

I'm sure they are verifiable because I've run the "peverify". This bothers
me actually: STRICTLY according to the ECMA verification rule, the example
where the .ctor-s of the same class (A) invoke each other and one .ctor
stores the "this" pointer in a local variable SHOULD be rejected by the
verifier. This does *not* happen.

So, what I suspect is that the ECMA verification rules do not match the
implementation of peverify.

Regards,

[quoted text, click to view]

Which says nothing about you undrstanding that its a verification rule, your
post came across as if you expected the code to simply not work. You never
mentioned actually trying to verify it using peverify or any other tool.
Remember no one can read your mind, you have to be explicit.

[quoted text, click to view]

It should, yes, but that it does not is not a problem with the standard.
peverify is not what I would consider the definate standard, but only an
implementation of it, one that is apparently not complete at that.
I am curious, have you tried running your code under a user account that
doesn't grant rights to unverifiable code(ie not an Administrator?) If this
particular problem exists in the runtime as well as in peverify, then that
may well be a significant problem (it certainly allows some ugly hacks, if
nothing else).

Also, if you could post a complete example of your IL I'll take a whack at
it with the newest verifier I have available, it might have been a bug in
the 1.x framework(which framework are you using, btw?). Until we see the 2.0
standard(assuming there is one), its impossible to say that the rule is
still in effect, but I assume it should be.

Hi Daniel,

[quoted text, click to view]

Sorry, you are right - I was not explicit enough.

[quoted text, click to view]

I tried after you suggested it. And the answer is the same.

[quoted text, click to view]

I'm using peverify 1.1.4322.573

Thank you very much for having a look at the code! Here is it:

==================================


// Microsoft (R) .NET Framework IL Disassembler. Version 1.1.4322.573
// Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.

..assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) //
..z\V.4..
.ver 1:0:5000:0
}
..assembly Test113
{
// --- The following custom attribute is added automatically, do not
uncomment -------
// .custom instance void
[mscorlib]System.Diagnostics.DebuggableAttribute::.ctor(bool,
//
bool) = ( 01 00 00 01 00 00 )
.hash algorithm 0x00008004
.ver 0:0:0:0
}
..module Test113.exe
// MVID: {732B486A-F0FA-451D-A4C6-FBD9B16BFF9F}
..imagebase 0x00400000
..subsystem 0x00000003
..file alignment 512
..corflags 0x00000001
// Image base: 0x03020000
//
// ============== CLASS STRUCTURE DECLARATION ==================
//
..class private auto ansi beforefieldinit Test
extends [mscorlib]System.Object
{
} // end of class Test

..class private auto ansi beforefieldinit A
extends [mscorlib]System.Object
{
} // end of class A

// =============================================================


// =============== GLOBAL FIELDS AND METHODS ===================


// =============================================================


// =============== CLASS MEMBERS DECLARATION ===================
// note that class flags, 'extends' and 'implements' clauses
// are provided here for information only

..class private auto ansi beforefieldinit Test
extends [mscorlib]System.Object
{
.method private hidebysig static void Main() cil managed
{
.entrypoint
// Code size 9 (0x9)
.maxstack 3
.locals init (class A V_0)
IL_0000: ldc.i4.1
IL_0001: ldc.i4.3
IL_0002: newobj instance void A::.ctor(int32,
int32)
IL_0007: stloc.0
IL_0008: ret
} // end of method Test::Main

.method public hidebysig specialname rtspecialname
instance void .ctor() cil managed
{
// Code size 7 (0x7)
.maxstack 1
IL_0000: ldarg.0
IL_0001: call instance void [mscorlib]System.Object::.ctor()
IL_0006: ret
} // end of method Test::.ctor

} // end of class Test

..class private auto ansi beforefieldinit A
extends [mscorlib]System.Object
{
.method public hidebysig specialname rtspecialname
instance void .ctor(int32 i,
int32 j) cil managed
{
.maxstack 3
.locals init (class A V_0)
ldarg 0
ldarg.1
ldarg.2
add
call instance void A::.ctor(int32)

// here we store the this pointer into a local var.
// this should be allowed by verifier only if the this is initialized
ldarg 0
stloc 0

ret
} // end of method A::.ctor

.method public hidebysig specialname rtspecialname
instance void .ctor(int32 i) cil managed
{
.maxstack 3
ldarg.0
ldarg.1
ldarg.1
call instance void A::.ctor(int32,int32)
ret
} // end of method A::.ctor

} // end of class A

'Initialization' in this context has only to do with the state of the
object, specifically the state of whether constructors have been called.

Your recursive example is verifiable because it will never return without
calling the base class constructor. Of course, it will never return,
period.

The 'uninitialized this on entering a try block' restriction is implemented
in PEVerify and the x64 & Itanium JIT verifiers for Whidbey Beta2. I
believe it is being considered for inclusion in ECMA.


[quoted text, click to view]

Thank you Matt,

[quoted text, click to view]

How does the verifier know that the example will never return. Isn't the
verification performed per method? Maybe I missunderstood ...

[quoted text, click to view]

Thank you for the info. What is actually the reason for not having an
uninitialized "this" in a try block?

Thank you again for the answers!
Best,

[quoted text, click to view]
A constructor must do one of two things before returning: call another
constructor of the same class or call a constructor of the base class.
Every other constructor must also obey the same rules. You can see that if
you have a class where no constructor calls the base class constructor
before returning, every constructor must instead call another constructor of
the same class for those constructors to be verifiable. The result is
infinite recursion -- none of the constructors will return.

Applying the rules on a per-method basis is sufficient to determine that
either the base class constructor is eventually called *or* the constructor
never returns. Since it operates on the per-method basis, the verifier
cannot know which of these is the case, but either one satisfies the
constraint in ECMA.

[quoted text, click to view]
To satisfy the requirements in 1.8.1.4 the verifier must determine that a
constructor is called on all paths from entry to exit. This can get
complicated in the presence of exception handling. In addition, the current
ECMA rules, while more lenient, do not actually give you much useful
flexibility.

example:
try {
call .baseCtor
}
catch
{
}
return

This is not a verifiable constructor because there is a path from entry to
return where no qualifying constructor is called. An exception could happen
before or during the call to .baseCtor, end up in the catch block, and
return. To make it verifiable you would have to transform the code to
something like:

example:
try {
call .baseCtor
}
catch
{
call .baseCtor
}
return

This insures that a qualifying constructor is called on all paths, but it
also leaves open the possibility that .baseCtor is called twice. This is
not illegal but it is usually undesirable.

Hope this helps,
Matt

Matt,

many thanks!! now everything is clear to me!