Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 6794] slow voip/sip call flow for large captures

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6794

--- Comment #9 from Cristian Constantin <const.crist@xxxxxxxxxxxxxx> 2012-02-06 07:03:22 PST ---
(In reply to comment #8)
> Looks nice!
> Shouldn't  callsinfo be freed?
>        
> tapinfo->callsinfo_hashtable[SIP_HASH]=g_hash_table_new_full(g_str_hash,
>                                                             g_str_equal,
>                                                             NULL, /*
> key_destroy_func */
>                                                              g_free);/*
> value_destroy_func */

cristian: both the key and the actual information stored in the hashtable
are also part of the list (still used, but not for look-up). they are still
freed like this in voip_calls_reset():

    list = g_list_first(tapinfo->callsinfo_list);
    while (list)
    {
        callsinfo = list->data;
        g_free(callsinfo->call_id);
        g_free(callsinfo->from_identity);
        g_free(callsinfo->to_identity);
        g_free((void *)(callsinfo->initial_speaker.data));
        g_free(callsinfo->protocol_name);
        g_free(callsinfo->call_comment);

        if (callsinfo->free_prot_info && callsinfo->prot_info)
            callsinfo->free_prot_info(callsinfo->prot_info);

        g_free(list->data);
        list = g_list_next(list);
    }
    g_list_free(tapinfo->callsinfo_list);

and after that the actual hash table is freed as well:

    /* free the SIP_HASH */
    if(NULL!=tapinfo->callsinfo_hashtable[SIP_HASH])
        g_hash_table_remove_all (tapinfo->callsinfo_hashtable[SIP_HASH]);

imo it should be o.k. (i.e. no memory leak here). what do you think?
(otoh, how do you test wireshark for memory leaks?)

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.