Hi Jukka,

On 11/11/2013 01:04 AM, Jukka Rissanen wrote:
Hi Anderson,

On pe, 2013-11-08 at 01:23 +0000, Anderson Briglia wrote:
Hi,

I have been using connman (current git master) + wpa_supplicant (2.0) and noticed that there is 
probably a race condition which is causing connmand to abort (sig 11) while performing a "scan 
wifi" and "enable/disable wifi".
Since the UI application I am using have a toggle to enable/disable wifi and 
request scan, sometimes connmand aborts. Using only connman provided utilities, 
I did the following test:

1. run "connmand -I eth0 -n -d"
2. From different terminal sessions, perform a "test-connman enable wifi" and 
"test-connman scan wifi" simultaneously. Keep enabling and disabling wifi and scanning 
until connmand crashes. The output from connmand debug messages is the following:

connmand[1542]: wlan0 {RX} 88 packets 20202 bytes
connmand[1542]: wlan0 {TX} 118 packets 17094 bytes
connmand[1542]: wlan0 {update} flags 4098 <DOWN>
connmand[1542]: wlan0 {newlink} index 4 address DE:AD:BE:F0:63:8B mtu 1500
connmand[1542]: wlan0 {newlink} index 4 operstate 2 <DOWN>
connmand[1542]: src/detect.c:detect_newlink() type 1 index 4
connmand[1542]: src/dnsproxy.c:try_remove_cache() No cache users, removing it.
connmand[1542]: src/technology.c:scan() technology 0xc1cc8 request from :1.31
connmand[1542]: src/technology.c:reply_scan_pending() technology 0xc1cc8 err -38
connmand[1542]: src/technology.c:reply_scan_pending() reply to :1.31
connmand[1542]: src/technology.c:set_property() conn 0xb4a88
connmand[1542]: src/technology.c:set_property() property Powered
connmand[1542]: src/technology.c:technology_enable() technology 0xc1cc8 enable
connmand[1542]: src/rfkill.c:__connman_rfkill_block() type 3 block 0
connmand[1542]: src/device.c:__connman_device_enable() device 0xc1ee8
connmand[1542]: src/technology.c:technology_save() technology 0xc1cc8
connmand[1542]: src/storage.c:storage_load() Loading /var/lib/connman/settings
connmand[1542]: src/rfkill.c:rfkill_process()
connmand[1542]: src/rfkill.c:rfkill_process() idx 1 type 1 op 2 soft 0 hard 0
connmand[1542]: src/technology.c:__connman_technology_update_rfkill() index 1 
soft 0 hard 0
connmand[1542]: src/technology.c:technology_find() type 3
connmand[1542]: src/technology.c:technology_apply_rfkill_change() technology 
0xc1cc8 --> 0/0 vs 1/0
connmand[1542]: src/device.c:__connman_device_enable() device 0xc1ee8
connmand[1542]: Aborting (signal 11) [connmand]
The above log snippet indicates weird issue as one cannot scan until the
device is enabled but that seems to happen here.

Using valgrind I could notice that there is a problem accessing struct *device 
by some methods:

The above crash and the free memory read below are related. It looks
like a ref count or similar memory issue.

==1580== Invalid read of size 4
==1580==    at 0x27E10: interface_scan_result (supplicant.c:2708)
==1580==    by 0x2B70F: method_call_reply (dbus.c:386)
==1580==    by 0x4ACFEA93: ??? (in /usr/lib/libdbus-1.so.3.7.2)
==1580==  Address 0x4d9ecd8 is 40 bytes inside a block of size 136 free'd
==1580==    at 0x480E8E0: free (in 
/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==1580==
==1580== Invalid read of size 4
==1580==    at 0x39D0C: connman_device_get_index (device.c:512)
==1580==    by 0x5319F: find_device (detect.c:39)
==1580==    by 0x532BB: detect_newlink (detect.c:69)
==1580==    by 0x5B44B: netlink_event (rtnl.c:472)
==1580==    by 0x4B026157: ??? (in /usr/lib/libglib-2.0.so.0.3400.3)
==1580==  Address 0x490baf8 is 56 bytes inside a block of size 84 free'd
==1580==    at 0x480E8E0: free (in 
/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==1580==
==1580== Invalid read of size 4
==1580==    at 0x3A380: __connman_device_enable (device.c:174)
==1580==    by 0x61707: technology_affect_devices (technology.c:659)
==1580==    by 0x61B1B: technology_enable (technology.c:684)
==1580==    by 0x61F53: set_property (technology.c:728)
==1580==    by 0x1627B: process_message (object.c:258)
==1580==    by 0x4ACFE147: ??? (in /usr/lib/libdbus-1.so.3.7.2)
==1580==  Address 0x490bb00 is 64 bytes inside a block of size 84 free'd
==1580==    at 0x480E8E0: free (in 
/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==1580==
==1580== Invalid read of size 4
==1580==    at 0x3A380: __connman_device_enable (device.c:174)
==1580==    by 0x61707: technology_affect_devices (technology.c:659)
==1580==    by 0x62773: technology_apply_rfkill_change (technology.c:1490)
==1580==    by 0x63887: __connman_technology_update_rfkill (technology.c:1586)
==1580==    by 0x5DA17: rfkill_process (rfkill.c:134)
==1580==    by 0x5DA83: rfkill_event (rfkill.c:150)
==1580==    by 0x4B026157: ??? (in /usr/lib/libglib-2.0.so.0.3400.3)
==1580==  Address 0x490bb00 is 64 bytes inside a block of size 84 free'd
==1580==    at 0x480E8E0: free (in 
/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==1580==

The host machine is running an ARM processor and connman packages were built 
using Yocto as build system.
Any hints how to fix that?
I was trying to reproduce this in x86 (with valgrind) but failed. A bit
more log is needed here.

I have seem that if you copy a provisioning file to trigger a connection while scanning/enabling/disabling
wifi it is easier to reproduce the bug.


Could you generate a new debug log (using valgrind if possible) and
paste is somewhere (do not send the full log to ml)? Also please add
--leak-check=full valgrind option.

You can find another valgrind log here: http://pastebin.com/uVRcFSHA
And I also added the output from python scripts: http://pastebin.com/aQZjygCi


Have you tried to use connmanctl instead of python test scripts to
enable/disable and scan? Does it change the outcome i.e., do you see the
crash?

Yes, I have tried and connmand aborts as well (signal 11). The test case is the same:
"connmanctl enable/disable wifi" and "connmanctl scan wifi".


Thanks,

-Anderson Briglia

Cheers,
Jukka



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

Reply via email to