[V4CC] VTable.Field() Vcursor.Field() and no leaks.

[Ernesto Giannotta]

Hi Ruslan,

thanks for taking the time to dig into this issue.


I've followed your exact steps and cursor example produces a lot of leaks here:

Leaked Object	#	Address	Size	Responsible Library	Responsible Frame
< multiple >	556	< multiple >	8896	V4CC	MakeREALInstance(fbl::smart_ptr<fbl::I_Field>)
Malloc 16 Bytes	506	< multiple >	8096	libvshared_fat_release.dylib	fbl_new(unsigned long, bool)
Malloc 16 Bytes	40	< multiple >	640	libvkernel_fat_release.dylib	yyFlexLexer::yylex()
Malloc 16 Bytes	40	< multiple >	640	libvkernel_fat_release.dylib	yyFlexLexer::yylex()
Malloc 16 Bytes	37	< multiple >	592	libvkernel_fat_release.dylib	yyFlexLexer::yylex()
Malloc 16 Bytes	 	0x1999120	16	libvkernel_fat_release.dylib	yyFlexLexer::yylex()
Malloc 16 Bytes	 	0x1999040	16	libvkernel_fat_release.dylib	yyFlexLexer::yylex()

and this is on first click only, every click produces ever more leaked objects!

This is the report produced if I only add "autorelease" to this line: 
	
	VField* pFld = [[pCursor fieldAtIndex:i] autorelease];

Leaked Object	#	Address	Size	Responsible Library	Responsible Frame
Malloc 16 Bytes	57	< multiple >	912	libvkernel_fat_release.dylib	yyFlexLexer::yylex()
Malloc 16 Bytes	53	< multiple >	848	libvkernel_fat_release.dylib	yyFlexLexer::yylex()
Malloc 16 Bytes	52	< multiple >	832	libvkernel_fat_release.dylib	yyFlexLexer::yylex()
Malloc 16 Bytes	 	0x1964410	16	libvkernel_fat_release.dylib	yyFlexLexer::yylex()
Malloc 16 Bytes	 	0x1964330	16	libvkernel_fat_release.dylib	yyFlexLexer::yylex()

as you can see the number of leaked objects is much much smaller...

if I comment out the VField casting loop I get this on about every click:

Leaked Object	#	Address	Size	Responsible Library	Responsible Frame
Malloc 16 Bytes	99	< multiple >	1584	libvkernel_fat_release.dylib	yyFlexLexer::yylex()
Malloc 16 Bytes	98	< multiple >	1568	libvkernel_fat_release.dylib	yyFlexLexer::yylex()
Malloc 16 Bytes	97	< multiple >	1552	libvkernel_fat_release.dylib	yyFlexLexer::yylex()

which seems to consistently report about 3 objects leak on every cursor creation...


I'm happy to confirm that the field casting from VTable produces very clean results i.e. no leaks at all!


I've made no check for zombies, since I never seen one and I'm too scared of such an otherwordly encounter! :-)

Just joking of course, maybe Thorsten can shed some light on this one.


Cool Runnings,
Erne.


On Sep 3, 2010, at 16:57, Ruslan Zasukhin wrote:

> Hi Erne,
> Hi Thorsten,
> 
> Today I have made attempt reproduce any leaks in V4CC with help of 
>     [tbl FieldAtIndex:i]
>     [curs FieldAtIndex:i]
> 
> And I have not found any leaks guys.
> I still think you have some mirage :-)
> 
> So I have take V4CC/Example/Sql_Way/Records_AddDeleteUpdate
> 
> ==============================================
> Then I have change method pbSelect to be as 
> 
> - (IBAction)pbSelect:(id)sender
> {
>     @try
>     { 
>         for( int i = 1; i <= 100 ; ++i )
>         {
>             VTable* pTable = [mDatabase tableForName:@"T1"];
>         
>             int Count = [pTable    fieldCount];
>             for( int i = 1; i <= Count ; ++i )
>             {
>                 VField* pFld = [pTable fieldAtIndex:i];
>             } 
>         } 
>     }
>     @catch(NSException* pe)
>     {
>         [mwPropertyPanel showError:[pe name] reason:[pe reason]];
>     }
> }
> 
> ==============================================
> - (IBAction)pbSelect:(id)sender
> {
>     @try
>     { 
>         NSString* query = @"SELECT * FROM T1 WHERE false";
> 
>         for( int i = 1; i <= 100 ; ++i )
>         {
>             NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
> 
>                 VCursor* pCursor = [mDatabase sqlSelect:query cursorLocation:EVCursorLocation_kServerSide 
>                             lockType:EVLockType_kReadWrite direction:EVCursorDirection_kRandom];
>         
>                 int Count = [pCursor fieldCount];
>                 for( int i = 1; i <= Count ; ++i )
>                 {
>                     VField* pFld = [pCursor fieldAtIndex:i];
>                 } 
>             
>             [pool release];
>         } 
>     }
>     @catch(NSException* pe)
>     {
>         [mwPropertyPanel showError:[pe name] reason:[pe reason]];
>     }
> }
> 
> 
> 
> AS you can see in first case I test VTable and in the second Vcursor.
> 
> 1) Note that Vtable* and Vfield* never are   retained, released or autoreleases.
> No need for this because of internal structure and tricks
> 
> There is nothing bad here guys, because RULES of course are rules,
> But they also mention that in some cases,  IF YOU KNOW something special,
> you can avoid do extra  retain/release calls.
> 
> Here we have exactly such special case.
> VDatabase is a root of tree of schema objects. 
>    VDatabase keeps tables and links. Tables keep fields, ...
>    V4CC designed in such way that we do not have overheads here.
> 
> 
> And only when Vdatabase object — ROOT will be release 
> And start destroy self it will destroy the whole tree, including both
> KERNEL objects and wow!  V4CC cocoa objects.
> 
> 
> 
> 2) VCursor test above is shown with NSAutoReleasePool usage.
> 
> VCursor is one more ROOT of tree, like VDatabase. 
> VCursor keeps  set of fields and is their owner. 
> NOT you. NOT your classes. VCursor is owner. 
> 
> So you can take fields by simple line:
>              VField* pFld = [pCursor fieldAtIndex:i];
> 
> And no need for any special steps here. 
> No need retain, no need release.
> 
> 
> ===========================================
> Once again, I have run this modified example project to search  
> Zombies, and later Leaks.
> 
> No Zombies.
> No Leaks...   There was only few minor by singlentons in vkernel.
> 
> If you still think that something is wrong, please 
> Take above example, copy above my code.
> Modify code to expose problem, and describe steps to see that problem.
> 
> 
> -- 
> Best regards,
> 
> Ruslan Zasukhin
> VP Engineering and New Technology
> Paradigma Software, Inc
> 
> Valentina - Joining Worlds of Information 
> http://www.paradigmasoft.com
> 
> [I feel the need: the need for speed]
> _______________________________________________
> Valentina mailing list
> Valentina at lists.macserve.net
> http://lists.macserve.net/mailman/listinfo/valentina

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macserve.net/pipermail/valentina/attachments/20100905/e5db792a/attachment.html>