MySQL Hiccup

Looks like mysql had a hiccup on webcodex yesterday causing a number of 
mails to the list to get bounced. Here were the ones bounced back to me:


On Sunday, August 3, 2003, at 07:21  PM, Stefano Corsi wrote:

>> 	/* Get the name of the member variable to dereference to from operand
>> 1 */
>> 	varn = uc_str(p, 1);
>>
>> By making these changes I think we avoid the varnames hashtable and
>> associated functions you propose in your patch. Is that right ?
>
> If it works it's much, much better!
> If you agree, I would branch on a memfix_0_20_1 or something like
> that, to
> make these corrections...

I think the main branch is fine for now ... plus I already committed
them there :)

>  There are more in the last patch I sent you. The
> one regarding motoi_new is also important because waste memory in loops
> containing many "new" external and internal objects.
>
> We have to move from:
>
> if(mfn != NULL) {
>         /* Call the constructor */
>         if(mfn->fptr != NULL)
>             r = motoi_callEDF(r,args,mfn);
>         else
>             motoi_callMDF(r,args,mfn);
>     }
>
> to
>
> if(mfn != NULL) {
>         /* Call the constructor */
>         if(mfn->fptr != NULL) {
>             moto_freeVal(env, r);

Ooo ... I didn't see the 'moto_freeVal(env, r);' line ... good catch!
Could you commit that on the main branch

>             r = motoi_callEDF(r,args,mfn);
>         } else {
>             moto_freeVal(env, motoi_callMDF(r,args,mfn));
>         }
>     }
>
>
> Stefano
>
-Dave


---------


Ok, I just applied, tested, and committed (on the main branch) the fix
for the constructor leak. I wouldn't exactly call this (or the strdup
issue) leaks because the memory did get cleaned up 'eventually' :) but
letting it hang around until the end of page execution was definitely
sub-optimal. Maybe we should call these 'deferred memory collection'
bugs :)

   	if(mfn != NULL) {
   		/* Call the constructor */
-		if(mfn->fptr != NULL)
+		if(mfn->fptr != NULL)
   			r = motoi_callEDF(r,args,mfn);
   		else
-			motoi_callMDF(r,args,mfn);
+			moto_freeVal(env, motoi_callMDF(r,args,mfn));
   	}

I've already committed fixes for

1) The motoi_assign issue - The fix I committed was basically the same
fix as yours
2) The moto_strdup for variable names issue - The fix I committed was a
different fix than your fix ... I didn't create a varnames table in env
... I just removed the moto_strdup :)

Did I miss any other fixes in your patch ?

   -Dave

-------


On Sunday, August 3, 2003, at 07:21  PM, Stefano Corsi wrote:

>> 	/* Get the name of the member variable to dereference to from operand
>> 1 */
>> 	varn = uc_str(p, 1);
>>
>> By making these changes I think we avoid the varnames hashtable and
>> associated functions you propose in your patch. Is that right ?
>
> If it works it's much, much better!
> If you agree, I would branch on a memfix_0_20_1 or something like
> that, to
> make these corrections...

I think the main branch is fine for now ... plus I already committed
them there :)

>  There are more in the last patch I sent you. The
> one regarding motoi_new is also important because waste memory in loops
> containing many "new" external and internal objects.
>
> We have to move from:
>
> if(mfn != NULL) {
>         /* Call the constructor */
>         if(mfn->fptr != NULL)
>             r = motoi_callEDF(r,args,mfn);
>         else
>             motoi_callMDF(r,args,mfn);
>     }
>
> to
>
> if(mfn != NULL) {
>         /* Call the constructor */
>         if(mfn->fptr != NULL) {
>             moto_freeVal(env, r);

Ooo ... I didn't see the 'moto_freeVal(env, r);' line ... good catch!
Could you commit that on the main branch

>             r = motoi_callEDF(r,args,mfn);
>         } else {
>             moto_freeVal(env, motoi_callMDF(r,args,mfn));
>         }
>     }
>
>
> Stefano
>
-Dave