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.
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.
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?
>
> Thanks,
>
> -Anderson Briglia
Cheers,
Jukka
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
