[Pnet-developers] A cross-assembly bug in cscc class resolution

[Gopal V]

Hi,
        I ran into the wierdest bug in pnet history tonight ... This is
way beyond wierd .. Ok the bug seems to be in image/ (*shudder*)
somewhere in the hashing lookups .. Here's how you run across it.

For one , you cannot make a single file test case , this has to be
cross assembly to create problems :-).. So here's the scenario, 
there are 2 classes named 'StringCollection' one in System.dll and
other in your .dll and your StringCollection is a NESTED class ..

So whenever you compile them against each other, cscc automatically
picks the wrong StringCollection ie the nested one , even though 
that namespace is not in the 'using' section and the other namespace
IS IN 'using' ..

I tracked it down till ILClassLookupGlobal() which ends up giving a
nested class (which is not how it's supposed to work, right ?) . After
which it entered a couple of function pointer based hashing functions
and about 40 minutes later and after lots of gdb, came up on the following 
lines of code...

image/context.c:132
        /* Do we only want types at the global level? */
        if(key->wantGlobal && classInfo->scope)
        {
                if((classInfo->scope->token & IL_META_TOKEN_MASK) !=
                                        IL_META_TOKEN_MODULE)
                {
                        return 0;
                }
        }

Then what does exactly ILClassLookupGlobal do ?

AFAIK, the reason a single compilation unit is not affected is because 
the conflicting class is not added to this class hash before lookup...

To round things off before moving onto a savannah test case , I would
like to try to fix this myself  ... any advice ?

Gopal
PS: this is a very real bug concerning System.dll and System.Drawing.dll
    with PrinterSettings.StringCollection nested class causing havoc 
@#@@address@hidden
--
the difference between insanity and genius is measured by success

cross-assem-bug.tgz
Description: GNU Zip compressed data