[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]Status of cscc and Qt#
From: |
Gopal V |
Subject: |
Re: [DotGNU]Status of cscc and Qt# |
Date: |
Wed, 6 Nov 2002 23:17:12 +0530 |
User-agent: |
Mutt/1.2.5i |
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.
- [DotGNU]Status of cscc and Qt#, Adam Treat, 2002/11/05
- Re: [DotGNU]Status of cscc and Qt#, Adam Treat, 2002/11/05
- Message not available
- Message not available
- Re: [DotGNU]Status of cscc and Qt#, Adam Treat, 2002/11/06
- Re: [DotGNU]Status of cscc and Qt#, Adam Treat, 2002/11/06
- Re: [DotGNU]Status of cscc and Qt#, Rhys Weatherley, 2002/11/06
- Re: [DotGNU]Status of cscc and Qt#, Adam Treat, 2002/11/06
- [DotGNU]The Intended usage of GNU software (was Treecc Ruby support), James Michael DuPont, 2002/11/06
- [DotGNU]Re: The Intended usage of GNU software (was Treecc Ruby support), Rhys Weatherley, 2002/11/06
- [DotGNU]Re: The Intended usage of GNU software (was Treecc Ruby support), James Michael DuPont, 2002/11/06
- Re: [DotGNU]Status of cscc and Qt#,
Gopal V <=
- Re: [DotGNU]Status of cscc and Qt#, Gopal V, 2002/11/06
- Re: [DotGNU]Status of cscc and Qt#, Adam Treat, 2002/11/06
- Re: [DotGNU]Status of cscc and Qt#, Rhys Weatherley, 2002/11/06
- Re: [DotGNU]Status of cscc and Qt#, Rhys Weatherley, 2002/11/06
- Re: [DotGNU]Status of cscc and Qt#, Adam Treat, 2002/11/06
- Re: [DotGNU]Status of cscc and Qt#, Rhys Weatherley, 2002/11/06