GNOME Bugzilla – Bug 773675
Warning about failing runtime check
Last modified: 2017-03-24 12:35:14 UTC
My WiFi connection is sometimes not so good, or I have a bad driver, but sometimes the message below is printed on the terminal `nm-applet` is executed from. ``` (nm-applet:1657): libnm-WARNING **: (nm-access-point.c:285):nm_access_point_connection_valid: runtime check failed: (ap_ssid != NULL) ```
This is still present in nm-applet 1.4.2. I believe this happens if the driver or device is buggy, and the WLAN just goes missing. In my case this happens with Linux 4.9.2 and the drive module r8712u from the staging tree. > r8712u: module is from the staging directory, the quality is unknown, you have been warned. In my opinion, the warning is only confusing. 1. If the WLAN is still recognized by NetworkManager (wpa_supplicant), then it should just reconnect. (No idea if that already happens.) 2. If the WLAN is not there anymore, the warning should be integrated in the UI, and a pop up window should be shown, telling the user that there was a problem with the WLAN or the device, and that they should reconnect the device, restart NetworkManager or choose a different WLAN.
Created attachment 345121 [details] [review] [patch] libnm: handle errors gracefully in nm_access_point_connection_valid() It's unclear why the warning is hit, and maybe that should be investigated further. On the other hand, it seems the assertions/warnings are just to strict and nm_access_point_connection_valid() should accept unexpected data. ... which of course, makes it harder to figure out why unexpected data is present in the first place. As for comment 2, that has nothing to do with the warnings that libnm prints. It may not even have anything to do with NetworkManager, but the driver only.
*** Bug 777774 has been marked as a duplicate of this bug. ***
(In reply to Thomas Haller from comment #2) > Created attachment 345121 [details] [review] [review] > [patch] libnm: handle errors gracefully in nm_access_point_connection_valid() > > It's unclear why the warning is hit, and maybe that should be investigated > further. > > On the other hand, it seems the assertions/warnings are just to strict and > nm_access_point_connection_valid() should accept unexpected data. ... which > of course, makes it harder to figure out why unexpected data is present in > the first place. Since the purpose of the function is to check if a connection is compatible with the AP, we should certainly accept unexpected data in the connection, but probably not in the AP. If the AP has incomplete data and the caller wants to activate a connection on it, probably there's a bug somewhere else. I think these warnings have some value and we should instead investigate if there are other bugs in the applet. Paul, can you try to run the applet in gdb with the G_DEBUG=fatal-warnings environment variable set and print the backtrace when the assertion hits?
(In reply to Beniamino Galvani from comment #4) […] > Paul, can you try to run the applet in gdb with the G_DEBUG=fatal-warnings > environment variable set and print the backtrace when the assertion hits? Finally I was able to reproduce it today under GDB. It looks like, the assertions always come twice after each other. I hope the missing GLIB debugging symbols won’t be a problem.
+ Trace 237214
Thread 3 (Thread 0xb52ffb40 (LWP 2003))
Continuing.
Created attachment 347599 [details] Output created from within GDB Please find another backtrace attached.
Hi, can you please do: nmcli general logging level DEBUG domains DEFAULT,WIFI_SCAN:TRACE and attach NM logs when the warnings appear? Also, a backtrace with glib symbols would be useful. Thanks!
Created attachment 348247 [details] journalctl -u NetworkManager -b | tee /dev/shm/20170319–journalctl–nm-messages.txt (In reply to Beniamino Galvani from comment #7) > Hi, can you please do: > > nmcli general logging level DEBUG domains DEFAULT,WIFI_SCAN:TRACE I changed the configuration file to use level *TRACE* for all domains. Hopefully, that works too. > and attach NM logs when the warnings appear? Please find them attached. > Also, a backtrace with glib symbols would be useful. Thanks!
+ Trace 237278
Created attachment 348248 [details] Full backtraces created with GDB The warning is normally shown twice. In this case it happened twice, so four times. For the second occurrence, `info registers` was run too.
Created attachment 348324 [details] [review] [PATCH] applet: ignore APs with hidden SSID when checking available APs So, the problem is that idle_check_avail_access_point_notification() calls nm_access_point_filter_connections() for all APs including ones that don't have an SSID because it's hidden; other existing callers of the function instead guarantee that the SSID is not NULL. I think that we should ignore any AP with no SSID in idle_check_avail_access_point_notification(), because they are hidden in the GUI and we don't want to raise notifications for them. Only patching nm_access_point_connection_valid() to return FALSE when no AP is passed would still display notifications for hidden APs. How about attached patch? (I believe patch in commit 2 should also be applied to make libnm more robust).
patch lgtm, but I think nm_access_point_connection_valid() should also get rid of all the g_warn_if_fail(). An NMAccessPoint is not invalid if those properties are missing, so it's wrong to have nm_access_point_connection_valid() raise warnings.
(In reply to Thomas Haller from comment #11) > patch lgtm, but I think nm_access_point_connection_valid() should also get > rid of all the g_warn_if_fail(). An NMAccessPoint is not invalid if those > properties are missing, so it's wrong to have > nm_access_point_connection_valid() raise warnings. Agree, patch from comment 2 should be applied as well. - g_warn_if_fail (ap_mode != NM_802_11_MODE_UNKNOWN); + if (ap_mode != NM_802_11_MODE_UNKNOWN) + return FALSE; Should be (ap_mode == NM_802_11_MODE_UNKNOWN).
Comment on attachment 345121 [details] [review] [patch] libnm: handle errors gracefully in nm_access_point_connection_valid() Commited as https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=b11b6038792a3da3f47717129580d7c661140291 after fixing mode check (comment 12).
nm-applet patch from comment 10 applied as: https://git.gnome.org/browse/network-manager-applet/commit/?id=174c00cdb88a87d1f52a5dd91a715fcead405609 Thanks for reporting this.