You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In what case does this happen? The only case
I can see is if the string is successfully encoded,
but the encoding results in a non-null terminated
string. That might cause problems, otherwise it
looks okay?
What I meant was that in the case of a parser marker
string like "es#iii" if the last "i" fails to convert, then the
buffer used for "es#" won't be freed up again.
mbrierst commented on Feb 10, 2003
mbrierstmannequin
Mannequin
More actions
Logged In: YES
user_id=670441
Ahhhh... thank you for your reply. I understand now.
I have a patch that gets rid of this problem by putting allocated
memory into a list of CObjects which are freed when exceptions occur.
The list is only created when necessary, to hopefully preserve efficiency
in most cases. It has to be passed around, so several function calls had
to be changed, and to do the cleanup on return I made a macro CLEANRETURN.
This patch also fixes a memory leak when the buffer_len pointer is NULL.
This isn't a big deal since the documentation says never to pass in a NULL
buffer_len.
And it fixes another leak when a string with encoded NULL's is passed in
(again not a big deal)
If you want, I have C code that can be called from python to demonstrate
any of these leaks. Let me know what you think of the patch/approach.
Activity
malemburg commentedon Jan 10, 2002
... if subsequent parsing fails, a buffer which was possibly
allocated by "es#" is not freed.
mbrierst commentedon Feb 7, 2003
Logged In: YES
user_id=670441
In what case does this happen? The only case
I can see is if the string is successfully encoded,
but the encoding results in a non-null terminated
string. That might cause problems, otherwise it
looks okay?
malemburg commentedon Feb 8, 2003
Logged In: YES
user_id=38388
What I meant was that in the case of a parser marker
string like "es#iii" if the last "i" fails to convert, then the
buffer used for "es#" won't be freed up again.
mbrierst commentedon Feb 10, 2003
Logged In: YES
user_id=670441
Ahhhh... thank you for your reply. I understand now.
I have a patch that gets rid of this problem by putting allocated
memory into a list of CObjects which are freed when exceptions occur.
The list is only created when necessary, to hopefully preserve efficiency
in most cases. It has to be passed around, so several function calls had
to be changed, and to do the cleanup on return I made a macro CLEANRETURN.
This patch also fixes a memory leak when the buffer_len pointer is NULL.
This isn't a big deal since the documentation says never to pass in a NULL
buffer_len.
And it fixes another leak when a string with encoded NULL's is passed in
(again not a big deal)
If you want, I have C code that can be called from python to demonstrate
any of these leaks. Let me know what you think of the patch/approach.
Index: Python/getargs.c
===================================================================
! CLEANRETURN(0, freelist, dofree);
}
}
}
! CLEANRETURN(1, freelist, dofree);
}
mbrierst commentedon Feb 11, 2003
Logged In: YES
user_id=670441
I submitted this as patch 684981 so it can be
attached to the report instead of pasted in.
Also, the patch there is nicer than the one here.
loewis commentedon May 3, 2003
Logged In: YES
user_id=21627
Fixed in getargs.c 2.100 (with patch 684981).