David Bremner <[email protected]> writes:
> David Bremner <[email protected]> writes:
>
>> I haven't had a chance to really track this down, but it seems there is
>> a memory error in notmuch new (or a maybe false positive from valgrind).
>>
>> Attached is the log from running "make memory-test OPTIONS=--medium" on
>> current git master (0e037c34).
>>
>> It looks like we talloc the message_id string with the message object as
>> parent, but it somehow outlives the message object.
>
> Sorry, that had a few commits beyond master.
>
> master (08343d3d) gives essentially the same log.
>
The log says the relevent piece of memory was freed at line 655 of database.cc,
which
is the g_hash_table_insert in the code
ref = _parse_message_id (ctx, refs, &refs);
if (ref && strcmp (ref, message_id)) {
g_hash_table_insert (hash, ref, NULL);
last_ref = ref;
}
According to the docs for g_hash_table_insert
If the key already exists in the GHashTable its current value is
replaced with the new value. If you supplied a value_destroy_func
when creating the GHashTable, the old value is freed using that
function. If you supplied a key_destroy_func when creating the
GHashTable, the passed key is freed using that function.
Since we do pass a key_destroy_func, it seems we are being naughty by
returning last_ref just below.
I'm not sure about the best solution; one option would be to drop the
key_destroy_func and manually talloc_free ref, something like
char *ref=NULL;
while (*refs) {
if (ref) talloc_free (ref);
ref = _parse_message_id (ctx, refs, &refs);
if (ref && strcmp (ref, message_id)) {
g_hash_table_insert (hash, ref, NULL);
last_ref = ref;
}
}
_______________________________________________
notmuch mailing list
[email protected]
https://notmuchmail.org/mailman/listinfo/notmuch
