Fix utf8 string conversion memory leak on Python 2 (#198) #239
Conversation
| @@ -1245,6 +1260,7 @@ rd_kafka_conf_t *common_conf_setup (rd_kafka_type_t ktype, | |||
| "as a callable function"); | |||
| rd_kafka_topic_conf_destroy(tconf); | |||
| rd_kafka_conf_destroy(conf); | |||
| Py_XDECREF(ks8); | |||
There was a problem hiding this comment.
I know it becomes inconsistent with the way ks is handled, but couldn't we just Py_XDECREF immediately so we only have it once and don't have to scatter it on all of these paths? In fact, it looks like we could do that for ks in some of the cases that have been converted here.
There was a problem hiding this comment.
On Python 2.x ks8 will point to another object than ks, namely the utf8 representation of ks, and since k is a char pointer to ks's underlying memory we must retain the reference until all usage of k is over.
On Python 3 ks8 will always be NULL, thus causing XDECREF to be a no-op.
There was a problem hiding this comment.
ack, makes sense. Kinda sucks that the API naming doesn't make it really obvious when you're getting internal data vs a completely new object.
| @@ -64,8 +64,15 @@ | |||
|
|
|||
| /** | |||
| * @returns Unicode Python object as char * in UTF-8 encoding | |||
| * @param uobjp might be set to NULL or a new object reference (depending | |||
There was a problem hiding this comment.
Along the same lines as my other comment -- why not Py_XDECREF immediately inside these methods? Doesn't seem like there would ever be a case where we'd want to save this intermediate data, especially since it is only an issue in Py2..
There was a problem hiding this comment.
I think this comment is misleading, it is not a new object reference to the original object, but a new object reference to an utf8 reprsentation object of the original object, do you object?
We need to keep and destroy the intermediary utf8 object on Python 2.