On Wed, Jan 27, 2016 at 10:06:32PM -0800, Naveen Singh wrote: > 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). Have you checked that this is actually a real memory leak? For example, run wpa_supplicant under valgrind and see whether such memory gets freed when the process exits. > 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. Are you sure it is not freed when wpa_supplicant process terminates? All the added network blocks should be freed at that point in time.. > 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?) Memory is allocated only if a new profile is added. There can be multiple profiles for a single SSID. > I am talking about this function: > struct wpa_ssid * wpa_config_add_network(struct wpa_config *config) This needs to add a new network profile and allocate memory for it. If you do not want more memory to be used, it is responsibility of the program managing wpa_supplicant (either through the control interface or through D-Bus) to re-use existing network profiles or remove profiles they have added. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
