Hi,
continuing the leaked objects issue, based on the sample sent by Pritpal...
#define QT_PTROF( oObj ) ( oObj:pPtr )
PROCEDURE Main()
Local oRect
oRect := QRect():new( 20,20,30,400 )
? oRect:left()
? oRect:top()
? oRect:right()
? oRect:bottom()
/*
Qt_QRect_destroy( QT_PTROF( oRect ) )
or
oRect:Destroy()
*/
oRect:Destroy()
RETURN
I executed the following test cases with debug_new:
Case 1:
// With this cpp function
// See: leakobj_with_delete.txt
HB_FUNC( QT_QRECT_DESTROY )
{
//hbqt_par_QRect( 1 )->~QRect();
delete hbqt_par_QRect( 1 );
}
Case 2:
// With this cpp function
// See: leakobj_without_delete.txt
HB_FUNC( QT_QRECT_DESTROY )
{
hbqt_par_QRect( 1 )->~QRect();
//delete hbqt_par_QRect( 1 );
}
Case 3:
// With this cpp function
// See: leakobj_with_destructor_and_delete.txt
HB_FUNC( QT_QRECT_DESTROY )
{
hbqt_par_QRect( 1 )->~QRect();
delete hbqt_par_QRect( 1 );
}
The resulted log files are attached.
The reserved heap size at the end goes to zero just in test case 1 and 3.
'delete: freed 0x80b5a60 (size 4, 0 bytes still allocated)'.
Test case 2 shows that QRect (with size 16 bytes) allocated by Qt remains on
the heap. 'delete: freed 0x8e8aa60 (size 4, 16 bytes still allocated).
Pritpal, could you please insert the delete operator in the destructors
logic? An another solution is to define a new Delete() method containing
just the delete operator.
In any case this second solution will help the further investigations.
Best regards,
István
-----Original Message-----
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Viktor Szakáts
Sent: 2009. szeptember 16. 17:19
To: Harbour Project Main Developer List.
Subject: Re: [Harbour] demoqt tests with debug_new - Leaked objects
Hi Pritpal,
>> Is this a property of QT itself, or the property of
>> Harbour wrappers?
>>
>
> It is a property of Qt itself.
> I have made extensive experiments as far as Harbour's
> parameter passing is concerned and have reached to the
> conclusion that it is harmless. Experiments with Qt's
> object destruction has given me weired results.
> For example:
>
> oRect := QRect():new( 20,20,30,400 )
> ? oRect:left() => 20
> ? oRect:top() => 20
> ? oRect:right() => 30
> ? oRect:bottom() => 400
>
> Qt_QRect_destroy( oRect )
> ? oRect:left() => 4534342 ( a long figure )
> ? oRect:top() => 8967354 ( another long figure )
> ? oRect:right() => 30
> ? oRect:bottom() => 400
>
> .cpp
>
> HB_FUNC( QT_QRECT_DESTROY )
> {
> delete hbqt_par_QRect( 1 );
> // OR/AND
> hbqt_par_QRect( 1 )->~QRect();
> }
>
> So even after destroy, oRect is an active pointer and
> only firts two slots are pointing to garbase. In theory
> after destroying it it should raise som error or appln
> must hang, but results are contrary.
>
> Though I have not given up, YET, on this issue,
> but at the face value ( till now ) it appears we cannot
> use Harbour-Qt for production level applications.
>
> NOTE: struggle is still on to overcome it.
Thanks for the explanation and details.
Could it be that QT uses some sort of lazy freeing of the
objects (f.e. to keep user apps not crash when doing object
access after freeing, and/or to maintain compatibility with
earlier QT lib releases, or there could be others reasons
also), so that actual freeing happens only later in a
"gc-like" phase? If so, maybe there is a way to control that
directly or indirectly.
Looks like an issue which would make QT unsuitable for
a lot of uses (embedded systems), so I'd guess they have
solved this issue somehow.
Some easy googling gave this result:
http://lists.trolltech.com/pipermail/qt-interest/2008-December/000458.html
This might help understanding its internals.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Leaked object at 0x86a2a18 (size 4, 0x2192b5d)
Leaked object at 0x86a2a60 (size 4, 0x216632d)
Leaked object at 0x86a2aa8 (size 96, 0x20ef093)
Leaked object at 0x86a2b50 (size 4, 0x2166a1d)
Leaked object at 0x86a2bc0 (size 4, 0x2192f5d)
Leaked object at 0x86a2c08 (size 96, 0x20ef093)
Leaked object at 0x86a2cb0 (size 4, 0x2192e2d)
Leaked object at 0x86a2cf8 (size 20, 0x2193264)
Leaked object at 0x86a4ed0 (size 20, 0x2193264)
Leaked object at 0x86a4f28 (size 20, 0x2193264)
Leaked object at 0x86a4f80 (size 20, 0x2193264)
Leaked object at 0x86a5008 (size 4, 0x21ee6ed)
Leaked object at 0x86a5050 (size 4, 0x21ee5ed)
Leaked object at 0x86a5098 (size 36, 0x20eff86)
Leaked object at 0x86a5100 (size 96, 0x20ef093)
Leaked object at 0x86a51a8 (size 80, 0x20f50c2)
Leaked object at 0x86a5240 (size 80, 0x20f50c2)
Leaked object at 0x86a53f8 (size 20, 0x2193264)
Leaked object at 0x86a5450 (size 20, 0x2193264)
*** 19 leaks found
delete: freed 0x86a5450 (size 20, 612 bytes still allocated)
delete: freed 0x86a53f8 (size 20, 592 bytes still allocated)
delete: freed 0x86a4f80 (size 20, 572 bytes still allocated)
delete: freed 0x86a4f28 (size 20, 552 bytes still allocated)
delete: freed 0x86a4ed0 (size 20, 532 bytes still allocated)
delete: freed 0x86a2cf8 (size 20, 512 bytes still allocated)
delete: freed 0x86a5240 (size 80, 432 bytes still allocated)
delete: freed 0x86a51a8 (size 80, 352 bytes still allocated)
delete: freed 0x86a5100 (size 96, 256 bytes still allocated)
delete: freed 0x86a5098 (size 36, 220 bytes still allocated)
delete: freed 0x86a5050 (size 4, 216 bytes still allocated)
delete: freed 0x86a5008 (size 4, 212 bytes still allocated)
delete: freed 0x86a2cb0 (size 4, 208 bytes still allocated)
delete: freed 0x86a2c08 (size 96, 112 bytes still allocated)
delete: freed 0x86a2bc0 (size 4, 108 bytes still allocated)
delete: freed 0x86a2a18 (size 4, 104 bytes still allocated)
delete: freed 0x86a2b50 (size 4, 100 bytes still allocated)
delete: freed 0x86a2aa8 (size 96, 4 bytes still allocated)
delete: freed 0x86a2a60 (size 4, 0 bytes still allocated)
Leaked object at 0x80b5a18 (size 4, 0x2192b5d)
Leaked object at 0x80b5a60 (size 4, 0x216632d)
Leaked object at 0x80b5aa8 (size 96, 0x20ef093)
Leaked object at 0x80b5b50 (size 4, 0x2166a1d)
Leaked object at 0x80b5bc0 (size 4, 0x2192f5d)
Leaked object at 0x80b5c08 (size 96, 0x20ef093)
Leaked object at 0x80b5cb0 (size 4, 0x2192e2d)
Leaked object at 0x80b5cf8 (size 20, 0x2193264)
Leaked object at 0x80b7ed0 (size 20, 0x2193264)
Leaked object at 0x80b7f28 (size 20, 0x2193264)
Leaked object at 0x80b7f80 (size 20, 0x2193264)
Leaked object at 0x80b8008 (size 4, 0x21ee6ed)
Leaked object at 0x80b8050 (size 4, 0x21ee5ed)
Leaked object at 0x80b8098 (size 36, 0x20eff86)
Leaked object at 0x80b8100 (size 96, 0x20ef093)
Leaked object at 0x80b81a8 (size 80, 0x20f50c2)
Leaked object at 0x80b8240 (size 80, 0x20f50c2)
Leaked object at 0x80b83f8 (size 20, 0x2193264)
Leaked object at 0x80b8450 (size 20, 0x2193264)
*** 19 leaks found
delete: freed 0x80b8450 (size 20, 612 bytes still allocated)
delete: freed 0x80b83f8 (size 20, 592 bytes still allocated)
delete: freed 0x80b7f80 (size 20, 572 bytes still allocated)
delete: freed 0x80b7f28 (size 20, 552 bytes still allocated)
delete: freed 0x80b7ed0 (size 20, 532 bytes still allocated)
delete: freed 0x80b5cf8 (size 20, 512 bytes still allocated)
delete: freed 0x80b8240 (size 80, 432 bytes still allocated)
delete: freed 0x80b81a8 (size 80, 352 bytes still allocated)
delete: freed 0x80b8100 (size 96, 256 bytes still allocated)
delete: freed 0x80b8098 (size 36, 220 bytes still allocated)
delete: freed 0x80b8050 (size 4, 216 bytes still allocated)
delete: freed 0x80b8008 (size 4, 212 bytes still allocated)
delete: freed 0x80b5cb0 (size 4, 208 bytes still allocated)
delete: freed 0x80b5c08 (size 96, 112 bytes still allocated)
delete: freed 0x80b5bc0 (size 4, 108 bytes still allocated)
delete: freed 0x80b5a18 (size 4, 104 bytes still allocated)
delete: freed 0x80b5b50 (size 4, 100 bytes still allocated)
delete: freed 0x80b5aa8 (size 96, 4 bytes still allocated)
delete: freed 0x80b5a60 (size 4, 0 bytes still allocated)
Leaked object at 0x8e8aa18 (size 4, 0x2192b5d)
Leaked object at 0x8e8aa60 (size 4, 0x216632d)
Leaked object at 0x8e8aaa8 (size 96, 0x20ef093)
Leaked object at 0x8e8ab50 (size 4, 0x2166a1d)
Leaked object at 0x8e8abc0 (size 4, 0x2192f5d)
Leaked object at 0x8e8ac08 (size 96, 0x20ef093)
Leaked object at 0x8e8acb0 (size 4, 0x2192e2d)
Leaked object at 0x8e8acf8 (size 20, 0x2193264)
Leaked object at 0x8e8ced0 (size 20, 0x2193264)
Leaked object at 0x8e8cf28 (size 20, 0x2193264)
Leaked object at 0x8e8cf80 (size 20, 0x2193264)
Leaked object at 0x8e8d008 (size 4, 0x21ee6ed)
Leaked object at 0x8e8d050 (size 4, 0x21ee5ed)
Leaked object at 0x8e8d098 (size 36, 0x20eff86)
Leaked object at 0x8e8d100 (size 96, 0x20ef093)
Leaked object at 0x8e8d1a8 (size 80, 0x20f50c2)
Leaked object at 0x8e8d240 (size 80, 0x20f50c2)
Leaked object at 0x8e8d3f8 (size 20, 0x2193264)
Leaked object at 0x8e8d450 (size 20, 0x2193264)
Leaked object at 0x8ea9b18 (size 16, 0x804d5e5)
*** 20 leaks found
delete: freed 0x8e8d450 (size 20, 628 bytes still allocated)
delete: freed 0x8e8d3f8 (size 20, 608 bytes still allocated)
delete: freed 0x8e8cf80 (size 20, 588 bytes still allocated)
delete: freed 0x8e8cf28 (size 20, 568 bytes still allocated)
delete: freed 0x8e8ced0 (size 20, 548 bytes still allocated)
delete: freed 0x8e8acf8 (size 20, 528 bytes still allocated)
delete: freed 0x8e8d240 (size 80, 448 bytes still allocated)
delete: freed 0x8e8d1a8 (size 80, 368 bytes still allocated)
delete: freed 0x8e8d100 (size 96, 272 bytes still allocated)
delete: freed 0x8e8d098 (size 36, 236 bytes still allocated)
delete: freed 0x8e8d050 (size 4, 232 bytes still allocated)
delete: freed 0x8e8d008 (size 4, 228 bytes still allocated)
delete: freed 0x8e8acb0 (size 4, 224 bytes still allocated)
delete: freed 0x8e8ac08 (size 96, 128 bytes still allocated)
delete: freed 0x8e8abc0 (size 4, 124 bytes still allocated)
delete: freed 0x8e8aa18 (size 4, 120 bytes still allocated)
delete: freed 0x8e8ab50 (size 4, 116 bytes still allocated)
delete: freed 0x8e8aaa8 (size 96, 20 bytes still allocated)
delete: freed 0x8e8aa60 (size 4, 16 bytes still allocated)
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
