Send connman mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."


Today's Topics:

   1. Fwd: observed memory leak in wpa_supplicant (Naveen Singh)


----------------------------------------------------------------------

Message: 1
Date: Fri, 29 Jan 2016 11:36:58 -0800
From: Naveen Singh <[email protected]>
To: [email protected]
Subject: Fwd: observed memory leak in wpa_supplicant
Message-ID:
        <CAGTDzKnbhZa=uv9QrnOT26b+vOdwkftnQ_nv0rdgAp3qbfiS=g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi All

This is the response that I got from hostapd community about the proposed
fix for memory leak.

Regards
Naveen
---------- Forwarded message ----------
From: Dan Williams <[email protected]>
Date: Thu, Jan 28, 2016 at 8:21 AM
Subject: Re: observed memory leak in wpa_supplicant
To: Naveen Singh <[email protected]>, [email protected]


On Wed, 2016-01-27 at 22:06 -0800, Naveen Singh wrote:
> Hi All
> We have been running some stress test of sending a deauth with reason
> code 6 and 7 from an AP to an associated client and monitoring the
> memory usage of wpa_supplicant. In our setup wpa_supplicant talks to
> connman over dbus. Running this stress test reveals memory leak in
> wpa
> supplicant (memory usage of wpa supplicant keeps on growing).
>
> For connection after getting disconnected connman does "AddNetwork"
> DBUS call to the previously connected SSID. This ends up causing
> memory to be allocated for struct wpa_ssid (os_zalloc called). At
> this
> time there is already a structure allocated for same SSID as a result
> of previous connection. Every connection ends up creating a memory
> which is never freed.
>
> This surely causes memory usage of wpa_supplicant to go up. Should
> not
> we be allocating memory only if that profile (for that SSID does not
> exist?)

The AddNetwork D-Bus call creates a new network configuration (eg, a
wpa_ssid).  It is the responsibility of the thing calling AddNetwork
(eg, connman) to track what network configurations it has already added
and to remove them when they are no longer in use.

Continuously calling AddNetwork without ever removing networks
previously created with AddNetwork would certainly lead to a memory
leak, but that is mis-use of the supplicant's API.

Connman does call RemoveNetwork when the internal network object is
disconnected, but that can happen in any number of cases.   I'd suggest
filing a bug with the Connman team to see if they can track it down.

Dan

> I am talking about this function:struct wpa_ssid *
> wpa_config_add_network(struct wpa_config *config)
> {
> int id;
> struct wpa_ssid *ssid, *last = NULL;
>
> id = -1;
> ssid = config->ssid;
> while (ssid) {
>         wpa_printf(MSG_ERROR, "wpa_config_add_network existing ssid
> is
> %p", ssid);
> if (ssid->id > id)
> id = ssid->id;
> last = ssid;
> ssid = ssid->next;
> }
> id++;
>
> ssid = os_zalloc(sizeof(*ssid));
> if (ssid == NULL)
> return NULL;
> ssid->id = id;
> if (last)
> last->next = ssid;
> else
> config->ssid = ssid;
>         wpa_printf(MSG_ERROR, "wpa_config_add_network added %p size
> %d", ssid, sizeof(*ssid));
>
> wpa_config_update_prio_list(config);
>
> return ssid;
> }
> Regards
>
> _______________________________________________
> Hostap mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/hostap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.01.org/pipermail/connman/attachments/20160129/a2584d6f/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman


------------------------------

End of connman Digest, Vol 3, Issue 24
**************************************

Reply via email to