Re: [DotGNU]Status of cscc and Qt#

[Gopal V]

If memory serves me right, Adam Treat wrote:
> in (unmanaged) 00 Qt.QNull:get_Instance ()

Huh ? ... I checked the generated bytecode from pnet and a dump of a Qt.dll
(QNull has not changed since the generator started)...

[-DUMP-]
        .method assembly static hidebysig specialname valuetype Qt.QNull 
                get_Instance() cil managed 
        {
                // Start of method header: 489ac
                .maxstack  8
        ?L489ad:
                ldsfld     valuetype Qt.QNull valuetype Qt.QNull::instance
                ret
        }
[-END-DUMP-]

[-START-PNET-]
        .method assembly static hidebysig specialname valuetype Qt.QNull 
get_Instance() cil managed 
        {
                // Start of method header: 479d8
                .maxstack  8
        ?L479d9:
                ldsfld     valuetype Qt.QNull valuetype Qt.QNull::instance
                ret
        }
[-END-PNET-]

So obviously the code is identical at bytecode level .... Dunno about 
assembler or linker issues . But I noticed some strange going ons in 
the dumped bytecode of (Qt.dll from 0.5.1) ... 

.cctor() for QNull
                ldsflda    valuetype Qt.QNull valuetype Qt.QNull::instance
                ldnull
                call       instance void Qt.QNull::.ctor(class System.Object 
dummy)
                ret

But the .locals init(valuetype Qt.QNull) is declared inside '.ctor' ....
So which would be run before which ? ... Or more correctly isn't '.cctor'
run before '.ctor' ?

> Uncaught exception: System.InvalidOperationException: An invalid operation 
> occurred
>         at System.GC.SuppressFinalize(Object)
>         at Qt.QtSupport.Dispose()

                /* We can only suppress finalization if the current method
                   has the same class as the object itself */

This is violated in this case, since QWidget->QObject->QtSupport is
not traced during that internal call ... viz the this still goes into
as 'QWidget' and method owner as 'QtSupport'.

"InvalidOperationException -- The caller of this method is not the same 
as the object passed to this method."

lib_gc.c: 91
fprintf(stderr,"<%s>\n",ILClass_Name(GetObjectClass(obj)); should
give you an idea if my assumption is correct ... (or a segfault otherwise).

In that case , as subclass check is needed (see IsSubClass in verify.c).
Which means it takes no time to solve at all ;-)

And the segfault is due to the finalizer being executed when this fails
(or so it seems to me)..

Gopal
-- 
shh.. be very,very quiet, I'm hunting bugs.