dotgnu-pnet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pnet-developers] [bug #4535] mscorlib value types being marked as regul


From: nobody
Subject: [Pnet-developers] [bug #4535] mscorlib value types being marked as regular classes
Date: Thu, 31 Jul 2003 11:40:41 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686) Gecko/20030521 Galeon/1.3.4 Debian/1.3.4.20030526-1

=================== BUG #4535: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4535&group_id=353

Changes by: Richard Baumann <address@hidden>
Date: Thu 07/31/03 at 11:40 (America/New_York)

------------------ Additional Follow-up Comments ----------------------------
I found this bug because mcs.exe is failing to verify, because of an initobj on 
System.Char. The IsCPPointer check in the INITOBJ case in verify_obj.c is 
failing because the ILType_FromValueType on classInfo is returning what appears 
to be garbage. The ILTypeIdentical fails as a result, and a verification 
exception is thrown. The attached file generates a dynamic assembly which, when 
run, gives the same verification exception, for the same reason.

------------------ Additional Bug Attachment  ----------------------------
File name: xyz.cs                         Size:1 KB
Generates a dynamic assembly which, when run, shows the problem.
http://savannah.gnu.org/bugs/download.php?group_id=353&amp;bug_id=4535&amp;bug_file_id=567



=================== BUG #4535: FULL BUG SNAPSHOT ===================


Submitted by: Rich333                 Project: DotGNU Portable.NET          
Submitted on: Wed 07/30/03 at 14:17
Category:  None                       Severity:  5 - Major                  
Bug Group:  None                      Resolution:  None                     
Assigned to:  None                    Status:  Open                         

Summary:  mscorlib value types being marked as regular classes

Original Submission:  The basic mscorlib value types (e.g. Int32, Char) are 
being marked as regular classes when referenced from other assemblies. This is 
causing things like initobj on these types to fail verification. Within 
mscorlib they seem to be treated properly. You can see things like "box        
class [mscorlib]System.Char" by "ildasm pnetlib/System/System.dll | grep 
System.Char". The problem appears to be in the ILClass attributes for these 
types. I printf'd the attribs for System.Char (at least, that's what the 
classInfo's ILClassName said it was) in the INITOBJ case in verify_obj.c and it 
came out as 0x2109. I'm not sure if the missing IL_META_TYPEDEF_SYSTEM_MASK 
bits are a part of the problem, but I know the missing 
IL_META_TYPEDEF_CLASS_SEMANTICS_MASK bits are.


Rich

Follow-up Comments
*******************

-------------------------------------------------------
Date: Thu 07/31/03 at 11:40         By: Rich333
I found this bug because mcs.exe is failing to verify, because of an initobj on 
System.Char. The IsCPPointer check in the INITOBJ case in verify_obj.c is 
failing because the ILType_FromValueType on classInfo is returning what appears 
to be garbage. The ILTypeIdentical fails as a result, and a verification 
exception is thrown. The attached file generates a dynamic assembly which, when 
run, gives the same verification exception, for the same reason.

-------------------------------------------------------
Date: Wed 07/30/03 at 20:49         By: rweather
The information that indicates that a type is a value type
is stored in the library assembly, not in the referencing
assembly.  There is no way in metadata to record this
in the reference.

The ildasm program only dumps a single assembly at a
time, without loading the dependencies.  And so sometimes
it needs to guess as to what the foreign type is.  This can
cause it to show "class" when you might expect "valuetype",
especially for "box" and "initobj" instructions.

Besides, the IL_META_TYPEDEF_VALUE_TYPE flag
is *not* used to mark value types.  A value type is anything
that inherits from "System.ValueType".  That flag is obsolete
and is not used any more by the ECMA specifications.

The runtime engine, which does load the dependencies,
will resolve the type, discover that it inherits from the
System.ValueType class, and then "know" that it is a
value type.

Do you have a test case that demonstrates a problem at
runtime, or was it just something you noticed in ildasm?


CC list is empty


File Attachments
****************

-------------------------------------------------------
Date: Thu 07/31/03 at 11:40  Name: xyz.cs  Size: 1KB   By: Rich333
Generates a dynamic assembly which, when run, shows the problem.
http://savannah.gnu.org/bugs/download.php?group_id=353&amp;bug_id=4535&amp;bug_file_id=567


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4535&group_id=353

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]