Re: Memory Leaks When Using Statistics (was Re: [PATCH 1/1]: Fix Memory-map and Double-free Errors in Statistics Handling (was Re: Connman-0.67 Crashes and/or Hangs on Start-up))
Hi Grant, Finally, I found some time for debugging. 2) Keeping connman in the stack, but changing the mapping from MAP_PRIVATE back to MAP_SHARED such that stats_file_setup fails with -EINVAL (due to being backed by a JFFS2 file system). Okay, that tells us at least if stats.c is not involved there is no memory leak elsewhere. That's kind of nice for the rest bad for me ;) I have run valgrind for a while and also monitoring the memory map of connman with pmap. I don't know if that's enough or good way trying to find memory leak. ConnMan run through the whole night with a bit of background traffic (mail client polling etc) and I couldn't see any change in the pmap The first entry looks like this: 22403: ./connmand -n -d src/stats.c Address Kbytes RSS Dirty Mode Mapping 0040 532 412 0 r-x-- connmand 00685000 36 36 20 rw--- connmand 01325000 132 120 120 rw---[ anon ] 00310500 124 108 0 r-x-- ld-2.13.so 00310521e000 4 4 4 r ld-2.13.so 00310521f000 4 4 4 rw--- ld-2.13.so 00310522 4 4 4 rw---[ anon ] 003105401604 652 0 r-x-- libc-2.13.so 0031055910002048 0 0 - libc-2.13.so 003105791000 16 16 8 r libc-2.13.so 003105795000 4 4 4 rw--- libc-2.13.so 003105796000 24 24 24 rw---[ anon ] 00310580 8 8 0 r-x-- libdl-2.13.so 0031058020002048 0 0 - libdl-2.13.so 003105a02000 4 4 4 r libdl-2.13.so 003105a03000 4 4 4 rw--- libdl-2.13.so 003105c0 92 56 0 r-x-- libpthread-2.13.so 003105c170002044 0 0 - libpthread-2.13.so 003105e16000 4 4 4 r libpthread-2.13.so 003105e17000 4 4 4 rw--- libpthread-2.13.so 003105e18000 16 4 4 rw---[ anon ] 00310640 28 16 0 r-x-- libxtables.so.5.0.0 0031064070002048 0 0 - libxtables.so.5.0.0 003106607000 4 4 4 rw--- libxtables.so.5.0.0 003106c0 28 20 0 r-x-- librt-2.13.so 003106c070002044 0 0 - librt-2.13.so 003106e06000 4 4 4 r librt-2.13.so 003106e07000 4 4 4 rw--- librt-2.13.so 00310740 92 44 0 r-x-- libresolv-2.13.so 0031074170002044 0 0 - libresolv-2.13.so 003107616000 4 4 4 r libresolv-2.13.so 003107617000 4 4 4 rw--- libresolv-2.13.so 003107618000 8 0 0 rw---[ anon ] 003107801048 424 0 r-x-- libglib-2.0.so.0.2600.0 0031079060002044 0 0 - libglib-2.0.so.0.2600.0 003107b05000 4 4 4 rw--- libglib-2.0.so.0.2600.0 003107b06000 4 4 4 rw---[ anon ] 00310840 268 208 0 r-x-- libdbus-1.so.3.5.2 0031084430002044 0 0 - libdbus-1.so.3.5.2 003108642000 4 4 4 r libdbus-1.so.3.5.2 003108643000 4 4 4 rw--- libdbus-1.so.3.5.2 00310b00 16 12 0 r-x-- libcap-ng.so.0.0.0 00310b0040002044 0 0 - libcap-ng.so.0.0.0 00310b203000 4 4 4 r libcap-ng.so.0.0.0 00310b204000 4 4 4 rw--- libcap-ng.so.0.0.0 7f295bebf000 4 4 0 r-x-- iospm.so 7f295bec2044 0 0 - iospm.so 7f295c0bf000 4 4 4 rw--- iospm.so 7f295c0c 24 24 24 rw---[ anon ] 7f295c0e2000 16 16 12 rw-s- ethernet_002481c57c73_cable.data 7f295c0e6000 28 24 0 r--s- gconv-modules.cache 7f295c0ed000 4 4 4 rw---[ anon ] 7fff6132b000 132 24 24 rw---[ stack ] 7fff613ff000 4 4 0 r-x--[ anon ] ff60 4 0 0 r-x--[ anon ] -- -- -- total kB 248202340 320 and the current (14 hours later) one looks like this: 22403: ./connmand -n -d src/stats.c Address Kbytes RSS Dirty Mode Mapping 0040 532 412 0 r-x-- connmand 00685000 36 36 20 rw--- connmand 01325000 132 120 120 rw---[ anon ] 00310500 124 108 0 r-x-- ld-2.13.so 00310521e000 4 4 4 r ld-2.13.so 00310521f000 4 4 4 rw--- ld-2.13.so 00310522 4 4 4 rw---[ anon ] 003105401604 652 0 r-x--
Re: [PATCH 1/1]: Fix Memory-map and Double-free Errors in Statistics Handling (was Re: Connman-0.67 Crashes and/or Hangs on Start-up)
Good Morning Grant, On 02/17/2011 11:48 PM, Grant Erickson wrote: On 2/17/11 12:13 PM, Daniel Wagner wrote: On 02/17/2011 05:38 PM, Grant Erickson wrote: Thanks for taking the time to submit a comment for the code detailing the motivation for selecting MAP_PRIVATE. I have done some more research to determine why the MAP_SHARED fails on my platform. From what I can see, this is a limitation of JFFS2. For it's mmap method, it specifies: % grep 'mmap' linux/fs/jffs2/*.c linux/fs/jffs2/file.c:.mmap =generic_file_readonly_mmap, So, in short, for JFFS2 users in a top-of-tree kernel, connman statistics will never work with a PROT_WRITE + MAP_SHARED mapping. Thanks for tracking this down. In this case, it might make sense to add some fallback. My idea is to use MAP_PRIVATE and write the whole contents into a file after a certain period. The whole idea behind MAP_SHARED is to make sure the data really hits the disk. But until now, nobody with deep understanding of filesystem under Linux has done a review. So the current approach might be bogus. So if you are fine with having a fallback to MAP_PRIVATE + periodic write a file, then we should add this feature. Opinions? Were I writing this anew, I think I'd have skipped the mmap altogether, maintained the statistics in memory and flushed things out to a file at the appropriate times. If I understand you correctly, then allocating a memory block and use the current append write to this block can easily implemented withouth the use of mmap. Instead of allocating per mmap we just have to use malloc (or the glib wrapper for it g_try_new0()) for this. Working with what's there, I think I'd do away with MAP_SHARED, convert the mapping to MAP_PRIVATE and then call msync within the _stats_update path. This should be fairly simple to achieve. All that is said, however, without a savvy perspective on how statistic are used within connman. I have only second hand knowledge about the garantees we have to provide on the numbers. Marcel told me there exists a requirement for mobile phone manufacturers to grantee that the statistic numbers are like 95% accurate. How this number is computed or derived from is unclear. From this we thought we need to make sure that we really write data to the disk and also do not have too much disk IO. Currently, there is for each update at max two pages to flush to the disk. As I said nobody of us was really sure if this is what is going to work as expected. So if you have a better understanding what is really needed please be my guest ;) I'm glad to learn here something! cheers, daniel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: Memory Leaks When Using Statistics (was Re: [PATCH 1/1]: Fix Memory-map and Double-free Errors in Statistics Handling (was Re: Connman-0.67 Crashes and/or Hangs on Start-up))
Hi Grant, On 17 February 2011 20:10, Grant Erickson maratho...@gmail.com wrote: To isolate the leaks, I systematically eliminated processes from the system until I was left with: - syslogd - klogd - wpa_supplicant - dbus-daemon - connmand I have run connmand under valgrind and it reports memory leaks in gsupplicant code. I sent earlier some memoryleak patches in various parts of connman but unfortunately I have lately had no time to find out where the latest supplicant leaks are. Regards, Jukka ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH 1/1]: Fix Memory-map and Double-free Errors in Statistics Handling (was Re: Connman-0.67 Crashes and/or Hangs on Start-up)
On 2/17/11 12:13 PM, Daniel Wagner wrote: On 02/17/2011 05:38 PM, Grant Erickson wrote: Thanks for taking the time to submit a comment for the code detailing the motivation for selecting MAP_PRIVATE. I have done some more research to determine why the MAP_SHARED fails on my platform. From what I can see, this is a limitation of JFFS2. For it's mmap method, it specifies: % grep 'mmap' linux/fs/jffs2/*.c linux/fs/jffs2/file.c:.mmap =generic_file_readonly_mmap, So, in short, for JFFS2 users in a top-of-tree kernel, connman statistics will never work with a PROT_WRITE + MAP_SHARED mapping. Thanks for tracking this down. In this case, it might make sense to add some fallback. My idea is to use MAP_PRIVATE and write the whole contents into a file after a certain period. The whole idea behind MAP_SHARED is to make sure the data really hits the disk. But until now, nobody with deep understanding of filesystem under Linux has done a review. So the current approach might be bogus. So if you are fine with having a fallback to MAP_PRIVATE + periodic write a file, then we should add this feature. Opinions? Were I writing this anew, I think I'd have skipped the mmap altogether, maintained the statistics in memory and flushed things out to a file at the appropriate times. Working with what's there, I think I'd do away with MAP_SHARED, convert the mapping to MAP_PRIVATE and then call msync within the _stats_update path. All that is said, however, without a savvy perspective on how statistic are used within connman. Best, Grant ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH 1/1]: Fix Memory-map and Double-free Errors in Statistics Handling (was Re: Connman-0.67 Crashes and/or Hangs on Start-up)
On 01/28/2011 10:39 PM, Grant Erickson wrote:
diff -aruN a/src/stats.c b/src/stats.c
--- a/src/stats.c 2011-01-28 13:20:49.248299633 -0800
+++ b/src/stats.c 2011-01-28 13:19:44.824306025 -0800
@@ -223,10 +223,18 @@
TFR(close(file-fd));
file-fd = -1;
- if (file-history_name != NULL)
+ if (file-history_name != NULL) {
g_free(file-history_name);
- g_free(file-name);
- g_free(file);
+ file-history_name = NULL;
+ }
+
+ if (file-name != NULL) {
+ g_free(file-name);
+ file-name = NULL;
+ }
+
+ if (file != NULL)
+ g_free(file);
}
I think the last check (file != NULL) is not necessary, because we do
derefence it several times above.
cheers,
daniel
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
Re: [PATCH 1/1]: Fix Memory-map and Double-free Errors in Statistics Handling (was Re: Connman-0.67 Crashes and/or Hangs on Start-up)
On 1/31/11 1:47 AM, Daniel Wagner wrote: On Fri, Jan 28, 2011 at 08:13:28PM -0800, Grant Erickson wrote: As far as I can see, the stats mapping is not published or shared outside of connman. If so, there's no reason to map it SHARED versus PRIVATE. From the mmap man pages: MAP_SHARED Share this mapping. Updates to the mapping are visible to other processes that map this file, and are carried through to the underlying file. The file may not actually be updated until msync(2) or munmap() is called. MAP_PRIVATE Create a private copy-on-write mapping. Updates to the mapping are not visible to other processes mapping the same file, and are not carried through to the underlying file. It is unspecified whether changes made to the file after the mmap() call are visible in the mapped region. The reason for picking MAP_SHARED was to be sure the changes in buffer really hits the file. I read that MAP_PRIVATE does not garantee this. This is reason I was picking MAP_SHARED together with msync. Daniel: Thanks for the clarification on the rationale for choosing MAP_SHARED. I'll have to do some digging in to determine why MAP_SHARED fails on the ARM/Linux 2.6.32 kernel. It might be beneficial to add the above comments to the source file for future reference. Best, Grant ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: Connman-0.67 Crashes and/or Hangs on Start-up
Hi Grant, On Sun, Jan 30, 2011 at 01:37:30PM -0800, Grant Erickson wrote: The requested log output is as follows. It would seem that the wifi.so plug-in and the wpa_supplicant are not even communicating: Correct. # /sbin/wpa_supplicant -ddd -t -u 1296422968.146540: Providing DBus service 'fi.epitest.hostap.WPASupplicant'. Your wpa_supplicant is built to only provide the legacy D-Bus interface, which is why the wifi.so plugin doesn't talk to it. I don't know if you build your wpa_supplicant yourself, but you can build it so that it supports both interfaces. (which is why I was asking for your wpa_supplicant .config file, i.e. the build config file wpa_supplicant uses). Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: Connman-0.67 Crashes and/or Hangs on Start-up
On 1/30/11 2:46 PM, Samuel Ortiz wrote: On Sun, Jan 30, 2011 at 01:37:30PM -0800, Grant Erickson wrote: The requested log output is as follows. It would seem that the wifi.so plug-in and the wpa_supplicant are not even communicating: Correct. # /sbin/wpa_supplicant -ddd -t -u 1296422968.146540: Providing DBus service 'fi.epitest.hostap.WPASupplicant'. Your wpa_supplicant is built to only provide the legacy D-Bus interface, which is why the wifi.so plugin doesn't talk to it. I don't know if you build your wpa_supplicant yourself, but you can build it so that it supports both interfaces. (which is why I was asking for your wpa_supplicant .config file, i.e. the build config file wpa_supplicant uses). Thanks for the clarification on which '.config' file was intended. I do build wpa_supplicant from source, the .config for which is: DBUS_INCLUDE := $(DBUSCFLAGS) DBUS_LIBS := $(DBUSLDFLAGS) DBUS_VERSION := $(DBUSVERSION) CFLAGS += $(OPENSSLCFLAGS) $(NETLINKCFLAGS) $(LINUXCFLAGS) wpa_supplicant: LIBS += $(DBUSLDFLAGS) $(OPENSSLLDFLAGS) $(NETLINKLDFLAGS) wpa_passphrase: LDFLAGS += $(OPENSSLLDFLAGS) CONFIG_DRIVER_WEXT=y CONFIG_DRIVER_NL80211=y CONFIG_DRIVER_WIRED=y CONFIG_LIBNL20=y CONFIG_IEEE8021X_EAPOL=y CONFIG_EAP_MD5=y CONFIG_EAP_MSCHAPV2=y CONFIG_EAP_TLS=y CONFIG_EAP_PEAP=y CONFIG_EAP_TTLS=y CONFIG_EAP_GTC=y CONFIG_EAP_OTP=y CONFIG_EAP_LEAP=y CONFIG_PKCS12=y CONFIG_CTRL_IFACE=y CONFIG_DEBUG_SYSLOG=y CONFIG_BACKEND=file CONFIG_PEERKEY=y CONFIG_CTRL_IFACE_DBUS=y CONFIG_DEBUG_FILE=y When last I'd tried setting CONFIG_CTRL_IFACE_DBUS_NEW=y around the connman-0.63 time frame, it caused wpa_supplicant to segment fault so I turned it off as it didn't seem necessary. I'll give it another go with connman-0.68 and the non-legacy wifi.so and see what happens. Thanks for the tip. Would it make sense, from a debugging perspective, to have the Wi-Fi plug-in emit some log message if it cannot find the new D-Bus interface? Best, Grant ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
RE: Connman-0.67 Crashes and/or Hangs on Start-up
Tried 0.68 (same as b1db3cb?) on AR242x with both default and -W wext, didn't see the crashes. Bests Jeff -Original Message- From: connman-boun...@connman.net [mailto:connman-boun...@connman.net] On Behalf Of Samuel Ortiz Sent: Saturday, January 29, 2011 8:52 AM To: Grant Erickson Cc: connman@connman.net Subject: Re: Connman-0.67 Crashes and/or Hangs on Start-up Hi Grant, On Fri, Jan 28, 2011 at 02:52:36PM -0800, Grant Erickson wrote: On Jan 28, 2011, at 10:09 AM, Grant Erickson wrote: On Jan 28, 2011, at 9:44 AM, Samuel Ortiz wrote: On Fri, Jan 28, 2011 at 09:06:12AM -0800, Grant Erickson wrote: FYI. I need to check against GIT top-of-tree and dig into this further; however, with: * Wireless 802.11 WEXT, connman-0.67 hangs on start-up Backtrace with wired: Please give us a gdb backtrace or run test/backtrace src/connmand log where log is the below trace. Also, a connman -d -n log would be more useful. Samuel: With the wired Ethernet issue debugged and patched, I've done more investigation on the wireless issue. The results are as follows: -- Version / Pluginwifi.so wifi_legacy.so == connman-0.67FAILS SUCCEEDS -- connman-b1db3cb FAILS N/A == So, it would appear that the non-legacy wifi plugin has issues with wireless extension devices. I'm testing this with my iwlagn chipset forced to run in wext mode only and that seems to work fine. Would you mind sharing the output of wpa_supplicant -ddd -t -u when running connmand on top of it ? Also could you please show us what your wpa_supplicant .config look like ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
RE: Connman-0.67 Crashes and/or Hangs on Start-up
I used meego netbook image on AspireOne ZG5 (IA32) with kernel 2.6.35.3-18.4 Bests Jeff -Original Message- From: Grant Erickson [mailto:maratho...@gmail.com] Sent: Sunday, January 30, 2011 9:45 AM To: Zheng, Jeff Cc: connman@connman.net Subject: Re: Connman-0.67 Crashes and/or Hangs on Start-up On 1/29/11 5:20 PM, Zheng, Jeff wrote: Tried 0.68 (same as b1db3cb?) on AR242x with both default and -W wext, didn't see the crashes. Jeff, Between you and Samuel, it's good to hear that both the Atheros AR242x and Intel IWLAGN work well with 0.68/b1db3cb under wireless extensions with the non-legacy Wi-Fi plug-in. Would I be correct in assuming that both you and Samuel are using a Core iX or Atom platform? Against what kernel version are you running? In my case, it's linux-2.6.32, armv7l and TI WLAN 127x, their TIWLAN WiLink 6.1.0.2.144 driver and firmware 6.1.0.0.335. With the stats bug resolved, this particular interface/driver combination no longer crashes, it simply makes no forward progress in scanning and establishing a connection. As cited below, I still owe Samuel a wpa_supplicant trace. Best, Grant -Original Message- From: connman-boun...@connman.net [mailto:connman-boun...@connman.net] On Behalf Of Samuel Ortiz Sent: Saturday, January 29, 2011 8:52 AM To: Grant Erickson Cc: connman@connman.net Subject: Re: Connman-0.67 Crashes and/or Hangs on Start-up Hi Grant, On Fri, Jan 28, 2011 at 02:52:36PM -0800, Grant Erickson wrote: On Jan 28, 2011, at 10:09 AM, Grant Erickson wrote: On Jan 28, 2011, at 9:44 AM, Samuel Ortiz wrote: On Fri, Jan 28, 2011 at 09:06:12AM -0800, Grant Erickson wrote: FYI. I need to check against GIT top-of-tree and dig into this further; however, with: * Wireless 802.11 WEXT, connman-0.67 hangs on start-up Backtrace with wired: Please give us a gdb backtrace or run test/backtrace src/connmand log where log is the below trace. Also, a connman -d -n log would be more useful. Samuel: With the wired Ethernet issue debugged and patched, I've done more investigation on the wireless issue. The results are as follows: -- Version / Plugin wifi.so wifi_legacy.so == connman-0.67 FAILS SUCCEEDS -- connman-b1db3cb FAILS N/A == So, it would appear that the non-legacy wifi plugin has issues with wireless extension devices. I'm testing this with my iwlagn chipset forced to run in wext mode only and that seems to work fine. Would you mind sharing the output of wpa_supplicant -ddd -t -u when running connmand on top of it ? Also could you please show us what your wpa_supplicant .config look like ? ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: Connman-0.67 Crashes and/or Hangs on Start-up
Hi Grant,
On Fri, Jan 28, 2011 at 09:06:12AM -0800, Grant Erickson wrote:
FYI. I need to check against GIT top-of-tree and dig into this further;
however, with:
* Wired Ethernet connected, connman-0.67 crashes on start-up
* Wireless 802.11 WEXT, connman-0.67 hangs on start-up
Backtrace with wired:
Please give us a gdb backtrace or run test/backtrace src/connmand log where
log is the below trace.
Also, a connman -d -n log would be more useful.
Cheers,
Samuel.
root@10784311-00016.local# /usr/sbin/connmand -n
connmand[444]: Connection Manager version 0.67
connmand[444]: Checking loopback interface settings
connmand[444]: System hostname is salmon.local
connmand[444]: Adding profile default
connmand[444]: Failed to open RFKILL control device
connmand[444]: lo {newlink} index 1 operstate 0 UNKNOWN
connmand[444]: eth0 {create} index 2 type 1 ETHER
connmand[444]: eth0 {RX} 431 packets 60468 bytes
connmand[444]: eth0 {TX} 61 packets 7521 bytes
connmand[444]: eth0 {update} flags 69699 UP,RUNNING,LOWER_UP
connmand[444]: eth0 {newlink} index 2 address 00:0c:29:4c:56:a2 mtu 1500
connmand[444]: eth0 {newlink} index 2 operstate 6 UP
connmand[444]: Create interface eth0 [ ethernet ]
connmand[444]: mmap error Invalid argument for
/var/lib/connman/stats/ethernet_000c294c56a2_cable.data
*** glibc detected *** /usr/sbin/connmand: double free or corruption
(fasttop): 0x00062a80 ***
=== Backtrace: =
/lib/libc.so.6(+0x7049c)[0x4025249c]
/lib/libc.so.6(cfree+0x98)[0x40257db8]
/lib/libglib-2.0.so.0(g_free+0x44)[0x4006ad28]
/usr/sbin/connmand[0x3e594]
/lib/libglib-2.0.so.0(+0x2ac10)[0x40052c10]
/lib/libglib-2.0.so.0(+0x2bf44)[0x40053f44]
/usr/sbin/connmand[0x3ece8]
/usr/sbin/connmand[0x2972c]
/usr/sbin/connmand[0x21dc4]
/usr/sbin/connmand(connman_network_set_connected+0x5c)[0x220f4]
/usr/lib/connman/plugins/ethernet.so(+0x1450)[0x403a4450]
/usr/sbin/connmand(connman_rtnl_add_newlink_watch+0xa4)[0x36ba4]
/usr/lib/connman/plugins/ethernet.so(+0x12d4)[0x403a42d4]
/usr/sbin/connmand[0x1fae8]
/usr/sbin/connmand[0x1c908]
/usr/sbin/connmand(connman_element_register+0xe8)[0x1e024]
/usr/sbin/connmand[0x337ac]
/usr/sbin/connmand[0x372f4]
/usr/sbin/connmand[0x37dc0]
/lib/libglib-2.0.so.0(+0x825c0)[0x400aa5c0]
/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1ec)[0x40062a68]
/lib/libglib-2.0.so.0(+0x3e0ec)[0x400660ec]
/lib/libglib-2.0.so.0(g_main_loop_run+0x174)[0x4006669c]
/usr/sbin/connmand[0x1add4]
/lib/libc.so.6(__libc_start_main+0x118)[0x401f74c4]
=== Memory map:
8000-0004c000 r-xp 1f:07 904/usr/sbin/connmand
00053000-00057000 rwxp 00043000 1f:07 904/usr/sbin/connmand
00057000-00078000 rwxp 00:00 0 [heap]
4000-4001f000 r-xp 1f:07 343/lib/ld-2.11.1.so
4001f000-4002 rwxp 00:00 0
40024000-40026000 rwxp 00:00 0
40026000-40027000 r-xp 0001e000 1f:07 343/lib/ld-2.11.1.so
40027000-40028000 rwxp 0001f000 1f:07 343/lib/ld-2.11.1.so
40028000-40117000 r-xp 1f:07 364/lib/libglib-2.0.so.0.2400.2
40117000-4011f000 ---p 000ef000 1f:07 364/lib/libglib-2.0.so.0.2400.2
4011f000-4012 rwxp 000ef000 1f:07 364/lib/libglib-2.0.so.0.2400.2
4012-40124000 r-xp 1f:07 797
/usr/lib/libgthread-2.0.so.0.2400.2
40124000-4012b000 ---p 4000 1f:07 797
/usr/lib/libgthread-2.0.so.0.2400.2
4012b000-4012c000 rwxp 3000 1f:07 797
/usr/lib/libgthread-2.0.so.0.2400.2
4012c000-40189000 r-xp 1f:07 356/lib/libdbus-1.so.3.5.1
40189000-40191000 ---p 0005d000 1f:07 356/lib/libdbus-1.so.3.5.1
40191000-40192000 r-xp 0005d000 1f:07 356/lib/libdbus-1.so.3.5.1
40192000-40193000 rwxp 0005e000 1f:07 356/lib/libdbus-1.so.3.5.1
40193000-4019b000 r-xp 1f:07 421/lib/libxtables.so.5.0.0
4019b000-401a2000 ---p 8000 1f:07 421/lib/libxtables.so.5.0.0
401a2000-401a3000 rwxp 7000 1f:07 421/lib/libxtables.so.5.0.0
401a3000-401b7000 r-xp 1f:07 408/lib/libresolv-2.11.1.so
401b7000-401be000 ---p 00014000 1f:07 408/lib/libresolv-2.11.1.so
401be000-401bf000 r-xp 00013000 1f:07 408/lib/libresolv-2.11.1.so
401bf000-401c rwxp 00014000 1f:07 408/lib/libresolv-2.11.1.so
401c-401c2000 rwxp 00:00 0
401c2000-401c6000 r-xp 1f:07 357/lib/libdl-2.11.1.so
401c6000-401cd000 ---p 4000 1f:07 357/lib/libdl-2.11.1.so
401cd000-401ce000 r-xp 3000 1f:07 357/lib/libdl-2.11.1.so
401ce000-401cf000 rwxp 4000 1f:07 357/lib/libdl-2.11.1.so
401cf000-401da000 r-xp 1f:07 776/usr/lib/libgcc_s.so.1
401da000-401e1000 ---p b000 1f:07 776/usr/lib/libgcc_s.so.1
401e1000-401e2000 rwxp a000 1f:07 776/usr/lib/libgcc_s.so.1
401e2000-4031d000 r-xp 1f:07 350/lib/libc-2.11.1.so
Re: Connman-0.67 Crashes and/or Hangs on Start-up
On Jan 28, 2011, at 9:44 AM, Samuel Ortiz wrote: On Fri, Jan 28, 2011 at 09:06:12AM -0800, Grant Erickson wrote: FYI. I need to check against GIT top-of-tree and dig into this further; however, with: * Wired Ethernet connected, connman-0.67 crashes on start-up * Wireless 802.11 WEXT, connman-0.67 hangs on start-up Backtrace with wired: Please give us a gdb backtrace or run test/backtrace src/connmand log where log is the below trace. Also, a connman -d -n log would be more useful. Samuel: First, the debug log for the Ethernet crash and wireless hang cases. Stay tuned for GDB back traces for each as well: Wired Ethernet crash: connmand[491]: Connection Manager version 0.67 connmand[491]: connman-0.67/src/storage.c:__connman_storage_init() connmand[491]: connman-0.67/src/element.c:__connman_element_init() connmand[491]: connman-0.67/src/element.c:connman_element_create() element 0x5ae20 connmand[491]: connman-0.67/src/element.c:__connman_element_initialize() element 0x5ae20 connmand[491]: connman-0.67/src/technology.c:__connman_technology_init() connmand[491]: connman-0.67/src/notifier.c:__connman_notifier_init() connmand[491]: connman-0.67/src/service.c:__connman_service_init() connmand[491]: connman-0.67/src/storage.c:connman_storage_register() storage 0x53fe0 name service connmand[491]: connman-0.67/src/provider.c:__connman_provider_init() connmand[491]: connman-0.67/src/notifier.c:connman_notifier_register() notifier 0x54114 name provider connmand[491]: connman-0.67/src/network.c:__connman_network_init() connmand[491]: connman-0.67/src/element.c:connman_driver_register() driver 0x53c88 name network connmand[491]: connman-0.67/src/device.c:__connman_device_init() connmand[491]: connman-0.67/src/storage.c:connman_storage_register() storage 0x53c5c name device connmand[491]: connman-0.67/src/element.c:connman_driver_register() driver 0x53c40 name device connmand[491]: connman-0.67/src/agent.c:__connman_agent_init() connmand[491]: connman-0.67/src/iptables.c:__connman_iptables_init() connmand[491]: connman-0.67/src/tethering.c:__connman_tethering_init() connmand[491]: connman-0.67/src/counter.c:__connman_counter_init() connmand[491]: connman-0.67/src/notifier.c:connman_notifier_register() notifier 0x54224 name ondemand connmand[491]: connman-0.67/src/manager.c:__connman_manager_init() connmand[491]: connman-0.67/src/notifier.c:connman_notifier_register() notifier 0x53cd8 name manager connmand[491]: connman-0.67/src/profile.c:__connman_profile_init() connmand[491]: connman-0.67/src/storage.c:connman_storage_register() storage 0x53f54 name profile connmand[491]: connman-0.67/src/config.c:__connman_config_init() connmand[491]: connman-0.67/src/config.c:read_configs() connmand[491]: connman-0.67/src/stats.c:__connman_stats_init() connmand[491]: connman-0.67/src/resolver.c:__connman_resolver_init() connmand[491]: connman-0.67/src/resolver.c:connman_resolver_register() resolver 0x5412c name resolvfile connmand[491]: connman-0.67/src/ipconfig.c:__connman_ipconfig_init() connmand[491]: connman-0.67/src/rtnl.c:__connman_rtnl_init() connmand[491]: connman-0.67/src/task.c:__connman_task_init() connmand[491]: connman-0.67/src/proxy.c:__connman_proxy_init() connmand[491]: connman-0.67/src/detect.c:__connman_detect_init() connmand[491]: connman-0.67/src/rtnl.c:connman_rtnl_register() rtnl 0x54140 name detect connmand[491]: connman-0.67/src/session.c:__connman_session_init() connmand[491]: connman-0.67/src/timeserver.c:__connman_timeserver_init() connmand[491]: connman-0.67/src/plugin.c:__connman_plugin_init() connmand[491]: Checking loopback interface settings connmand[491]: System hostname is salmon.local connmand[491]: connman-0.67/src/utsname.c:connman_utsname_driver_register() driver 0x403a2340 name loopback connmand[491]: connman-0.67/src/network.c:connman_network_driver_register() driver 0x403acd4c name cable connmand[491]: connman-0.67/src/device.c:connman_device_driver_register() driver 0x403acd6c name ethernet connmand[491]: connman-0.67/src/element.c:__connman_element_foreach() connmand[491]: connman-0.67/src/element.c:foreach_callback() element 0x5ae20 name root connmand[491]: connman-0.67/src/technology.c:connman_technology_driver_register() driver 0x403acd28 name cdc_ethernet connmand[491]: connman-0.67/src/timeserver.c:connman_timeserver_driver_register() driver 0x40398658 name ntpd connmand[491]: connman-0.67/src/network.c:connman_network_driver_register() driver 0x4038e400 name wifi connmand[491]: connman-0.67/src/technology.c:connman_technology_driver_register() driver 0x4038e3dc name wifi connmand[491]: connman-0.67/src/resolver.c:connman_resolver_append() interface lo domain (null) server 127.0.0.1 connmand[491]: connman-0.67/src/resolver.c:append_resolver() interface lo domain (null) server 127.0.0.1 lifetime 0 flags 0 connmand[491]: connman-0.67/src/resolver.c:resolvfile_append() interface lo server 127.0.0.1
Re: Connman-0.67 Crashes and/or Hangs on Start-up
On Jan 28, 2011, at 10:09 AM, Grant Erickson wrote: On Jan 28, 2011, at 9:44 AM, Samuel Ortiz wrote: On Fri, Jan 28, 2011 at 09:06:12AM -0800, Grant Erickson wrote: FYI. I need to check against GIT top-of-tree and dig into this further; however, with: * Wired Ethernet connected, connman-0.67 crashes on start-up * Wireless 802.11 WEXT, connman-0.67 hangs on start-up Backtrace with wired: Please give us a gdb backtrace or run test/backtrace src/connmand log where log is the below trace. The wired Ethernet crash GDB backtrace: #0 0x4020e2ec in raise () from /lib/libc.so.6 #1 0x40213b04 in abort () from /lib/libc.so.6 #2 0x40247ee8 in __libc_message () from /lib/libc.so.6 #3 0x4025249c in malloc_printerr () from /lib/libc.so.6 #4 0x40257db8 in free () from /lib/libc.so.6 #5 0x4006ad28 in IA__g_free (mem=0x64950) at glib/glib-2.24.2/glib/gmem.c:191 #6 0x0003e684 in stats_free (user_data=value optimized out) at connman/connman-b1db3cb/src/stats.c:227 #7 0x40052c10 in g_hash_table_remove_node (hash_table=0x5bc60, node=0x61110, notify=-1097179325) at glib/glib-2.24.2/glib/ghash.c:449 #8 0x40053f44 in g_hash_table_remove_internal (hash_table=0x5bc60, key=0x64758, notify=1) at glib/glib-2.24.2/glib/ghash.c:1095 #9 0x0003edd8 in __connman_stats_service_register (service=0x64758) at connman/connman-b1db3cb/src/stats.c:671 #10 0x000288a8 in __connman_service_indicate_state (service=0x64758, state=CONNMAN_SERVICE_STATE_CONFIGURATION) at connman/connman-b1db3cb/src/service.c:3097 #11 0x00021864 in set_connected_dhcp (user_data=value optimized out) at connman/connman-b1db3cb/src/network.c:723 #12 set_connected (user_data=value optimized out) at connman/connman-b1db3cb/src/network.c:811 #13 0x00021b94 in connman_network_set_connected (network=0x64380, connected=1) at connman/connman-b1db3cb/src/network.c:866 #14 0x40386450 in add_network (flags=69699, change=0, user_data=value optimized out) at connman/connman-b1db3cb/plugins/ethernet.c:109 #15 ethernet_newlink (flags=69699, change=0, user_data=value optimized out) at connman/connman-b1db3cb/plugins/ethernet.c:132 #16 0x00036d28 in connman_rtnl_add_newlink_watch (index=2, callback=0x40386320 ethernet_newlink, user_data=0x62c00) at connman/connman-b1db3cb/src/rtnl.c:249 #17 0x403862d4 in ethernet_probe (device=0x62c00) at connman/connman-b1db3cb/plugins/ethernet.c:157 #18 0x0001f4c0 in device_probe (element=value optimized out) at connman/connman-b1db3cb/src/device.c:1212 #19 0x0001c2bc in probe_element (element=0x62c00) at connman/connman-b1db3cb/src/element.c:1011 #20 0x0001d9d8 in register_element (element=0x62c00, parent=value optimized out) at connman/connman-b1db3cb/src/element.c:1050 #21 connman_element_register (element=0x62c00, parent=value optimized out) at connman/connman-b1db3cb/src/element.c:1121 #22 0x000336a0 in detect_newlink (type=value optimized out, index=value optimized out, flags=value optimized out, change=value optimized out) at connman/connman-b1db3cb/src/detect.c:78 #23 0x00037478 in process_newlink (type=1, index=2, flags=69699, change=0, msg=0xbe9a5ba8, bytes=229188) at connman/connman-b1db3cb/src/rtnl.c:474 #24 0x00037f44 in rtnl_newlink (chan=value optimized out, cond=value optimized out, data=value optimized out) at connman/connman-b1db3cb/src/rtnl.c:862 #25 rtnl_message (chan=value optimized out, cond=value optimized out, data=value optimized out) at connman/connman-b1db3cb/src/rtnl.c:1302 #26 netlink_event (chan=value optimized out, cond=value optimized out, data=value optimized out) at connman/connman-b1db3cb/src/rtnl.c:1353 #27 0x400aa5c0 in g_io_unix_dispatch (source=0x61480, callback=0x37924 netlink_event, user_data=0x0) at glib/glib-2.24.2/glib/giounix.c:162 #28 0x40062a68 in g_main_dispatch (context=0x5c200) at glib/glib-2.24.2/glib/gmain.c:1960 #29 IA__g_main_context_dispatch (context=0x5c200) at glib/glib-2.24.2/glib/gmain.c:2513 #30 0x400660ec in g_main_context_iterate (context=0x5c200, block=value optimized out, dispatch=value optimized out, self=value optimized out) at glib/glib-2.24.2/glib/gmain.c:2591 #31 0x4006669c in IA__g_main_loop_run (loop=0x5b9b8) at glib/glib-2.24.2/glib/gmain.c:2799 #32 0x0001a7e0 in main (argc=1, argv=0xbe9a5e64) at connman/connman-b1db3cb/src/main.c:247 ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: Connman-0.67 Crashes and/or Hangs on Start-up
On Jan 28, 2011, at 10:09 AM, Grant Erickson wrote: On Jan 28, 2011, at 9:44 AM, Samuel Ortiz wrote: On Fri, Jan 28, 2011 at 09:06:12AM -0800, Grant Erickson wrote: FYI. I need to check against GIT top-of-tree and dig into this further; however, with: * Wireless 802.11 WEXT, connman-0.67 hangs on start-up Backtrace with wired: Please give us a gdb backtrace or run test/backtrace src/connmand log where log is the below trace. Also, a connman -d -n log would be more useful. Samuel: With the wired Ethernet issue debugged and patched, I've done more investigation on the wireless issue. The results are as follows: -- Version / Pluginwifi.so wifi_legacy.so == connman-0.67FAILS SUCCEEDS -- connman-b1db3cb FAILS N/A == So, it would appear that the non-legacy wifi plugin has issues with wireless extension devices. Regards, Grant ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH 1/1]: Fix Memory-map and Double-free Errors in Statistics Handling (was Re: Connman-0.67 Crashes and/or Hangs on Start-up)
On Jan 28, 2011, at 6:14 PM, Samuel Ortiz sa...@linux.intel.com wrote: On Fri, Jan 28, 2011 at 01:39:09PM -0800, Grant Erickson wrote: On Jan 28, 2011, at 12:10 PM, Grant Erickson wrote: On Jan 28, 2011, at 10:09 AM, Grant Erickson wrote: On Jan 28, 2011, at 9:44 AM, Samuel Ortiz wrote: On Fri, Jan 28, 2011 at 09:06:12AM -0800, Grant Erickson wrote: FYI. I need to check against GIT top-of-tree and dig into this further; however, with: * Wired Ethernet connected, connman-0.67 crashes on start-up * Wireless 802.11 WEXT, connman-0.67 hangs on start-up Backtrace with wired: Please give us a gdb backtrace or run test/backtrace src/connmand log where log is the below trace. The following patch fixes the core dump / fault issue, of which there were/are two core problems: 1) Trying to memory map the statistics file on armv7l-linux-unknown-gnu with MAP_SHARED results in a result value from mmap of MAP_FAILED. Using MAP_PRIVATE works correctly. This primary failure causes the secondary failure that leads to the segment fault. Why does this toolchain fail to build a SHARED mapping? That's the platform: Linux-2.6.32 2) The function stats_free, called indirectly from g_hash_table_remove(stats_hash, service), g_free(file-name) ends up double-freeing file-name. It had already been earlier freed in stats_file_setup, following the failure of status_file_remap. This part of the patch makes sense, I'll apply it. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH 1/1]: Fix Memory-map and Double-free Errors in Statistics Handling (was Re: Connman-0.67 Crashes and/or Hangs on Start-up)
On 1/28/11 6:14 PM, Samuel Ortiz wrote: On Fri, Jan 28, 2011 at 01:39:09PM -0800, Grant Erickson wrote: On Jan 28, 2011, at 12:10 PM, Grant Erickson wrote: On Jan 28, 2011, at 10:09 AM, Grant Erickson wrote: On Jan 28, 2011, at 9:44 AM, Samuel Ortiz wrote: On Fri, Jan 28, 2011 at 09:06:12AM -0800, Grant Erickson wrote: FYI. I need to check against GIT top-of-tree and dig into this further; however, with: * Wired Ethernet connected, connman-0.67 crashes on start-up * Wireless 802.11 WEXT, connman-0.67 hangs on start-up Backtrace with wired: Please give us a gdb backtrace or run test/backtrace src/connmand log where log is the below trace. The following patch fixes the core dump / fault issue, of which there were/are two core problems: 1) Trying to memory map the statistics file on armv7l-linux-unknown-gnu with MAP_SHARED results in a result value from mmap of MAP_FAILED. Using MAP_PRIVATE works correctly. This primary failure causes the secondary failure that leads to the segment fault. Why does this toolchain fail to build a SHARED mapping ? Samuel: Regrets about the last post, a premature send on the phone. The package builds without issue with the toolchain, Sourcery G++ 2010q1-202. Cited above, armv7l-linux-unknown-gnu is the platform, running Linux 2.6.32. As far as I can see, the stats mapping is not published or shared outside of connman. If so, there's no reason to map it SHARED versus PRIVATE. Best, Grant ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
