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-- libc-2.
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: [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: 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 02/17/2011 07:10 PM, Grant Erickson wrote:
Daniel:
In temporarily making the change in my local tree from MAP_SHARED to
MAP_PRIVATE against connman-0.68 to allow statistic to function against a
JFFS2 file system, one of the things I started noticing is that memory
started leaking proportionally to the amount of network activity and then at
a fixed baseline rate with no network activity (see attached).
Woot, thanks for the nice graph!
To isolate the leaks, I systematically eliminated processes from the system
until I was left with:
- syslogd
- klogd
- wpa_supplicant
- dbus-daemon
- connmand
These system physical memory leaks stopped under two conditions:
1) Eliminating connman entirely from the network stack (top data series with
y-intercept of 33513.
- In this scenario, I simply connected to the network using
/etc/wpa_supplicant.conf
I don't think that MAP_SHARED and MAP_PRIVATE should make a difference
here. Though I have to check the docs and the code. If there is a memory
leak in stats.c then I should also see it with MAP_SHARED and a ext4
file system. I have to verify that.
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 ;)
Has most of the testing connman received, particularly statistics, to date
been on systems with swap devices and ext{2,3,4}-based file systems?
I have developed and tested the code on a Fedora 12/13 system with ext4.
I was pretty sure that I didn't leak memory, but well your numbers tell
me differently. I'll try to reproduce that.
Thanks for your debugging efforts!
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)
Hi Grant, On 02/17/2011 05:38 PM, Grant Erickson wrote: 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 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, Also, the "TODO" comment is instructive. From linux/fs/jffs2/TODO: - support asynchronous operation -- add a per-fs 'reserved_space' count, let each outstanding write reserve the _maximum_ amount of physical space it could take. Let GC flush the outstanding writes because the reservations will necessarily be pessimistic. With this we could even do shared writable mmap, if we can have a fs hook for do_wp_page() to make the reservation. 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? 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 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 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 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, Also, the "TODO" comment is instructive. From linux/fs/jffs2/TODO: - support asynchronous operation -- add a per-fs 'reserved_space' count, let each outstanding write reserve the _maximum_ amount of physical space it could take. Let GC flush the outstanding writes because the reservations will necessarily be pessimistic. With this we could even do shared writable mmap, if we can have a fs hook for do_wp_page() to make the reservation. So, in short, for JFFS2 users in a top-of-tree kernel, connman statistics will never work with a PROT_WRITE + MAP_SHARED mapping. 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 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
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). Samuel: Thanks again for the pointers. With wpa_supplicant recompiled to provide support for the "new" D-Bus interface, the proprietary TI wireless extensions driver, wpa_supplicant-0.7.3 and connman-0.68 all work together and successfully establish a wireless connection. 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)
Hi Grant, 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. cheers, daniel ___ 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
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/28/11 4:51 PM, Samuel Ortiz wrote: > On Fri, Jan 28, 2011 at 02:52:36PM -0800, Grant Erickson wrote: >> 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 ? Samuel: As promised, the contents of /etc/wpa_supplicant.conf file is, as expected, empty. The contents of /etc/dbus-1/system.d/wpa_supplicant.conf is: http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";> The requested log output is as follows. It would seem that the wifi.so plug-in and the wpa_supplicant are not even communicating: # /sbin/wpa_supplicant -ddd -t -u & 1296422968.146540: Providing DBus service 'fi.epitest.hostap.WPASupplicant'. # /usr/sbin/connmand -n -d connmand[303]: Connection Manager version 0.67 connmand[303]: connman-0.67/src/storage.c:__connman_storage_init() connmand[303]: connman-0.67/src/element.c:__connman_element_init() connmand[303]: connman-0.67/src/element.c:connman_element_create() element 0x5cfd0 connmand[303]: connman-0.67/src/element.c:__connman_element_initialize() element 0x5cfd0 connmand[303]: connman-0.67/src/technology.c:__connman_technology_init() connmand[303]: connman-0.67/src/notifier.c:__connman_notifier_init() connmand[303]: connman-0.67/src/service.c:__connman_service_init() connmand[303]: connman-0.67/src/storage.c:connman_storage_register() storage 0x53ff8 name service connmand[303]: connman-0.67/src/provider.c:__connman_provider_init() connmand[303]: connman-0.67/src/notifier.c:connman_notifier_register() notifier 0x5412c name provider connmand[303]: connman-0.67/src/network.c:__connman_network_init() connmand[303]: connman-0.67/src/element.c:connman_driver_register() driver 0x53ca0 name network connmand[303]: connman-0.67/src/device.c:__connman_device_init() connmand[303]: connman-0.67/src/storage.c:connman_storage_register() storage 0x53c74 name device connmand[303]: connman-0.67/src/element.c:connman_driver_register() driver 0x53c58 name device connmand[303]: connman-0.67/src/agent.c:__connman_agent_init() connmand[303]: connman-0.67/src/iptables.c:__connman_iptables_init() connmand[303]: connman-0.67/src/tethering.c:__connman_tethering_init() connmand[303]: connman-0.67/src/counter.c:__connman_counter_init() connmand[303]: connman-0.67/src/notifier.c:connman_notifier_register() notifier 0x5423c name ondemand connmand[303]: connman-0.67/src/manager.c:__connman_manager_init() connmand[303]: connman-0.67/src/notifier.c:connman_notifier_register() notifier 0x53cf0 name manager connmand[303]: connman-0.67/src/profile.c:__connman_profile_init() connmand[303]: connman-0.67/src/storage.c:connman_storage_register() storage 0x53f6c name profile connmand[303]: connman-0.67/src/config.c:__connman_config_init() connmand[303]: connman-0.67/src/config.c:read_configs() connmand[303]: connman-0.67/src/stats.c:__connman_stats_init() connmand[303]: connman-0.67/src/resolver.c:__connman_resolver_init() connmand[303]: connman-0.67/src/resolver.c:connman_resolver_register() resolver 0x54144 name resolvfile connmand[303]: connman-0.67/src/ipconfig.c:__connman_ipconfig_init() connmand[303]: connman-0.67/src/rtnl.c:__connman_rtnl_init() connmand[303]: connman-0.67/src/task.c:__connman_task_init() connmand[303]: connman-0.67/src/proxy.c:__connman_proxy_init() connmand[303]: connman-0.67/src/detect.c:__connman_detect_init() connmand[303]: connman-0.67/src/rtnl.c:connman_rtnl_register() rtnl 0x54158 name detect connmand[303]: connman-0.67/src/session.c:__connman_session_init() connmand[303]: connman-0.67/src/timeserver.c:__connman_timeserver_init() connmand[303]: connman-0.67/src/plugin.c:__connman_plugin_init() connmand[303]: Checking loopback interface settings connmand[303]: System hostname is salmon.local connmand[303]: System domainname is domain.actdsltmp connmand[303]: connman-0.67/src/utsname.c:connman_utsname_driver_register() driver 0x40390340 name loopback connmand[303]: connman-0.67/src/network.
Re: Connman-0.67 Crashes and/or Hangs on Start-up
On 1/30/11 1:52 AM, Kalle Valo wrote: > Grant Erickson writes: >> 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. > > TI's WiLink driver might behave oddly and simply have bugs in it's wext > interface. I strongly recommend to use the proper upstream driver > wl12xx: > > http://linuxwireless.org/en/users/Drivers/wl12xx > > In the long run you will save a lot of trouble. For example, it will > work with wpasupplicant and connman out of box, thanks to mac80211 > stack. Out-of-tree drivers are always pain, avoid them like the plague. Kalle: Thanks for the link and recommendation. I am in 100% agreement with you on out-of-tree drivers and between connman and power management, I've first-hand experience that the proprietary driver has not been without issue. 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, Grant Erickson writes: > 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. TI's WiLink driver might behave oddly and simply have bugs in it's wext interface. I strongly recommend to use the proper upstream driver wl12xx: http://linuxwireless.org/en/users/Drivers/wl12xx In the long run you will save a lot of trouble. For example, it will work with wpasupplicant and connman out of box, thanks to mac80211 stack. Out-of-tree drivers are always pain, avoid them like the plague. -- Kalle Valo ___ 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 > > >> 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
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 >> 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
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 > 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: [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 > 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
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 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 > 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)
Hi Grant, 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 > >>> 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 ? > 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: 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 > >> 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
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 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
[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 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
>>> 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.
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.
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);
}
static void update_first(struct stats_file *file)
@@ -280,7 +288,7 @@
if (file->addr == NULL) {
addr = mmap(NULL, new_size, PROT_READ | PROT_WRITE,
- MAP_SHARED, file->fd, 0);
+ MAP_PRIVATE, file->fd, 0);
} else {
addr = mremap(file->addr, file->len, new_size, MREMAP_MAYMOVE);
}
Best regards,
Grant
___
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: >>> >>> * 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 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=) 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=) at connman/connman-b1db3cb/src/network.c:723 #12 set_connected (user_data=) 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=) at connman/connman-b1db3cb/plugins/ethernet.c:109 #15 ethernet_newlink (flags=69699, change=0, user_data=) at connman/connman-b1db3cb/plugins/ethernet.c:132 #16 0x00036d28 in connman_rtnl_add_newlink_watch (index=2, callback=0x40386320 , 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=) 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=) at connman/connman-b1db3cb/src/element.c:1050 #21 connman_element_register (element=0x62c00, parent=) at connman/connman-b1db3cb/src/element.c:1121 #22 0x000336a0 in detect_newlink (type=, index=, flags=, change=) 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=, cond=, data=) at connman/connman-b1db3cb/src/rtnl.c:862 #25 rtnl_message (chan=, cond=, data=) at connman/connman-b1db3cb/src/rtnl.c:1302 #26 netlink_event (chan=, cond=, data=) at connman/connman-b1db3cb/src/rtnl.c:1353 #27 0x400aa5c0 in g_io_unix_dispatch (source=0x61480, callback=0x37924 , 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=, dispatch=, self=) 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 9:06 AM, 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 Confirmed identical behavior with commit b1db3cb. 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
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 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
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 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
> connmand[444]: eth0 {create} index 2 type 1
> connmand[444]: eth0 {RX} 431 packets 60468 bytes
> connmand[444]: eth0 {TX} 61 packets 7521 bytes
> connmand[444]: eth0 {update} flags 69699
> connmand[444]: eth0 {newlink} index 2 address 00:0c:29:4c:56:a2 mtu 1500
> connmand[444]: eth0 {newlink} index 2 operstate 6
> 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-x
Connman-0.67 Crashes and/or Hangs on Start-up
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:
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
connmand[444]: eth0 {create} index 2 type 1
connmand[444]: eth0 {RX} 431 packets 60468 bytes
connmand[444]: eth0 {TX} 61 packets 7521 bytes
connmand[444]: eth0 {update} flags 69699
connmand[444]: eth0 {newlink} index 2 address 00:0c:29:4c:56:a2 mtu 1500
connmand[444]: eth0 {newlink} index 2 operstate 6
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
4031d000-40325000 ---p 0013b000 1f:07 350/lib/libc-2.11.1.so
40325000-40327000 r-xp 0013b000 1f:07 350/lib/libc-2.11.1.so
40327000-40328000 rwxp 0013d000 connmand[444]: Aborting (signal 6)
connmand[444]: backtrace
connmand[444]: [0]: /lib/libc.so.6(__default_sa_restorer_v2+0) [0x4020f630]
connmand[444]: [1]: /lib/libc.so.6(gsigna
