Hi Pierre,
> > > I have downloaded and compiled connman-0.55. It segfaults at launch,
> > > before I can do anything.
> > >
> > > It is cross-compiled for embedded arm platform. I have disabled the dhcp
> > > and udhcpc plugins (however even if I enable the udhcpc plugin the
> > > problem still occurs). It seems to crash in some dhcp code (as the two
> > > last debug messages are "connmand[1494]: plugins/dhcp.c:dhcp_request()
> > > dhcp 0x48c78
> > > connmand[1494]: src/utsname.c:connman_utsname_get_hostname()")
> > >
> > > I can't find any reference to a similar problem on the mailing list.
> > > Here's the backtrace :
> >
> > if you could run this through gdb and get a real backtrace that would
> > help. However I pushed a fix into the tree that checks the hostname
> > first if it is valid. Maybe your system for some reasons doesn't set a
> > hostname (and you are not using the loopback plugin).
>
> You were right, I was not using the loopback plugin. That caused
> connman_utsname_get_hostname to return NULL. So, in dhcp_request, when
> calling g_dhcp_client_set_send, parameter option_value is NULL. Then in
> get_hostname, the first test (g_strcmp0("<hostname>", host) != 0)
> succeeds, so it returns a g_strdup(NULL), which leads to a segfault in
> strnlen in alloc_dhcp_option.
>
> Does this (mini)patch seem reasonable ?
the magic for using gethostname() if the provided hostname is NULL is
just wrong. In that case we should not send the request at all. If we
don't have a hostname, we just don't have a hostname. Period.
I pushed a fix for that. Can you please try it out.
Regards
Marcel
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
