[gentoo-embedded] Everything that touches the network segfaults...

[gentoo-embedded] Everything that touches the network segfaults...

[Ed W]

Hi, I am building an embedded system and I have a certain config which 
is all working well, until I change and enable UCLIBC_USE_NETLINK=y and 
UCLIBC_SUPPORT_AI_ADDRCONFIG=y in uclibc-0.30.1 config

As soon as I enable the second option then I start getting segfaults 
whenever I run anything that tries to use the network (eg busybox ping, 
dropbear, busybox telnet).  ifconfig works fine, as does bringing up the 
interface

The build environment is gentoo-hardened (gcc 3.4.6) with uclibc-0.30.1 
and busybox 1.14.2.  The build environment is a 32bit chroot on a 64bit 
kernel.  The target machine is an x86 alix board

What is very odd is that if I chroot into the build on the build machine 
then ping, etc works fine.  However, with a different kernel (but very 
similar) on the alix board I get these segfaults.  I have switched the 
target to a 2.6.29.6 vanilla kernel to try and eliminate that - the 
build machine is running 2.6.29.6 64bit with some patches (hardened+vserver)

Obviously it's going to be a pain to turn on symbols and try to get a 
backtrace on the embedded board, so hoping someone has some other ideas?


Grateful for any thoughts?

Ed W

[gentoo-embedded] Re: Everything that touches the network segfaults...

[Ed W]

Ed W wrote:
> Hi, I am building an embedded system and I have a certain config which 
> is all working well, until I change and enable UCLIBC_USE_NETLINK=y 
> and UCLIBC_SUPPORT_AI_ADDRCONFIG=y in uclibc-0.30.1 config
>
> As soon as I enable the second option then I start getting segfaults 
> whenever I run anything that tries to use the network (eg busybox 
> ping, dropbear, busybox telnet). ifconfig works fine, as does bringing 
> up the interface
>
> The build environment is gentoo-hardened (gcc 3.4.6) with 
> uclibc-0.30.1 and busybox 1.14.2. The build environment is a 32bit 
> chroot on a 64bit kernel. The target machine is an x86 alix board
>
> What is very odd is that if I chroot into the build on the build 
> machine then ping, etc works fine. However, with a different kernel 
> (but very similar) on the alix board I get these segfaults. I have 
> switched the target to a 2.6.29.6 vanilla kernel to try and eliminate 
> that - the build machine is running 2.6.29.6 64bit with some patches 
> (hardened+vserver)
>
> Obviously it's going to be a pain to turn on symbols and try to get a 
> backtrace on the embedded board, so hoping someone has some other ideas?


Below is the backtrace from the crash - can anyone please help 
interpret? Looks like an issue with getaddrinfo and the 
SUPPORT_AI_ADDRECONFIG option?


(gdb) bt full
#0 0xb7fe6327 in __check_pf () at libc/inet/getaddrinfo.c:191
ifa = (struct ifaddrs *) 0x968bb38
runp = (struct ifaddrs *) 0x968bdcc
seen = 0
#1 0xb7fe6560 in gaih_inet (name=0xbfcbee68 "192.168.105.4", service=0x0,
req=0xbfcbe964, pai=0xbfcbe924) at libc/inet/getaddrinfo.c:418
nullserv = {next = 0xb801b244, socktype = -1077155576,
protocol = -1207841846, port = 134522499}
tp = (const struct gaih_typeproto *) 0xb7ffb520
st = (struct gaih_servtuple *) 0xbfcbe8a4
at = (struct gaih_addrtuple *) 0x0
rc = 0
v4mapped = 0
seen = 3087118916
__PRETTY_FUNCTION__ = "gaih_inet"
#2 0xb7fe760c in *__GI_getaddrinfo (name=0xbfcbee68 "192.168.105.4",
service=0x0, hints=0xbfcbe964, pai=0xbfcbe960)
at libc/inet/getaddrinfo.c:860
i = 0
j = 1
last_i = 0
p = (struct addrinfo *) 0x0
end = (struct addrinfo **) 0xbfcbe924
g = (const struct gaih *) 0xb80006b8
pg = (const struct gaih *) 0xb80006b8
gaih_service = {name = 0xb801cb1a "\211D$(\203�\ba�\004",
num = -1207848920}
pservice = (struct gaih_service *) 0x0
default_hints = {ai_flags = -1208060929, ai_family = 134525712,
ai_socktype = 298, ai_protocol = 134515904, ai_addrlen = 134522288,
ai_addr = 0x804bca0, ai_canonname = 0x7 <Address 0x7 out of bounds>,
ai_next = 0xb801cb25}
#3 0x080cef16 in str2sockaddr (host=0xbfcbee68 "192.168.105.4", port=0, 
af=0,
ai_flags=2) at libbb/xconnect.c:213
rc = 0
r = (len_and_sockaddr *) 0x0
result = (struct addrinfo *) 0x0
used_res = (struct addrinfo *) 0xbfcbe984
org_host = 0xbfcbee68 "192.168.105.4"
cp = 0xbfcbe984 ""
hint = {ai_flags = 0, ai_family = 0, ai_socktype = 1, ai_protocol = 0,
ai_addrlen = 0, ai_addr = 0x0, ai_canonname = 0x0, ai_next = 0x0}
#4 0x080cefaa in xhost_and_af2sockaddr (host=0x0, port=-1207958740, 
af=65192)
at libbb/xconnect.c:252
No locals.
#5 0x08068714 in ping_main (argc=2, argv=0xbfcbebf4) at 
networking/ping.c:750
af = 812
lsa = (len_and_sockaddr *) 0x0
str_s = 0xb7fa0c3c ""
opt = 0
#6 0x0804df9a in run_applet_no_and_exit (applet_no=176, argv=0xbfcbebf4)
at libbb/appletlib.c:732
argc = 2
#7 0x0804dfbe in run_applet_and_exit (name=0xbfcbee63 "ping", 
argv=0xbfcbebf4)
at libbb/appletlib.c:739
applet = 0
#8 0x0804e1fe in main (argc=2, argv=0xbfcbebf4) at libbb/appletlib.c:776

Re: [gentoo-embedded] Re: Everything that touches the network segfaults...

[Peter Stuge]

Ed W wrote:
> Below is the backtrace from the crash - can anyone please help interpret? 

I googled "uclibc libc/inet/getaddrinfo.c" to find the source, and
found a patch right around line 191..


> #0 0xb7fe6327 in __check_pf () at libc/inet/getaddrinfo.c:191

http://lists.uclibc.org/pipermail/uclibc-cvs/2008-December/025767.html


//Peter

Re: [gentoo-embedded] Re: Everything that touches the network segfaults...

[Ed W]

Peter Stuge wrote:
> Ed W wrote:
>   
>> Below is the backtrace from the crash - can anyone please help interpret? 
>>     
>
> I googled "uclibc libc/inet/getaddrinfo.c" to find the source, and
> found a patch right around line 191..
>
>
>   
>> #0 0xb7fe6327 in __check_pf () at libc/inet/getaddrinfo.c:191
>>     
>
> http://lists.uclibc.org/pipermail/uclibc-cvs/2008-December/025767.html
>
>   

Yay, thanks.  Posted first, ate dinner second, should have used google 
somewhere earlier on...

Will post a patch to bugs.g.o. 

Curiously the patch was from Dec, and 0.9.30.1 dates well after that.  
Agree that it's not in the changelog, though - shame

Thanks !

Ed W

Re: [gentoo-embedded] Re: Everything that touches the network segfaults...

[Ed W]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

Peter Stuge wrote:
> Ed W wrote:
>   
>> Below is the backtrace from the crash - can anyone please help interpret? 
>>     
>
> I googled "uclibc libc/inet/getaddrinfo.c" to find the source, and
> found a patch right around line 191..
>
>
>   
>> #0 0xb7fe6327 in __check_pf () at libc/inet/getaddrinfo.c:191
>>     
>
> http://lists.uclibc.org/pipermail/uclibc-cvs/2008-December/025767.html
>
>   

Does the second part of that patch make sense to anyone?

Ed

[-- Attachment #2: Type: text/html, Size: 1072 bytes --]

Re: [gentoo-embedded] Re: Everything that touches the network segfaults...

[Peter Stuge]

Ed W wrote:
>> http://lists.uclibc.org/pipermail/uclibc-cvs/2008-December/025767.html
>
> Does the second part of that patch make sense to anyone?

The comment is that it's just cosmetic. In practice it removes a
cast, but if the file builds without warnings also without that hunk
then it does not matter at all. calloc() should return void * so the
cast shouldn't really be needed, but also does no harm.


//Peter

[gentoo-embedded] Re: Everything that touches the network segfaults...

[Ed W]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

Denys Vlasenko wrote:
> On Monday 20 July 2009 22:23, Ed W wrote:
>   
>> Ed W wrote:
>>     
>>
>> Below is the backtrace from the crash - can anyone please help 
>> interpret? Looks like an issue with getaddrinfo and the 
>> SUPPORT_AI_ADDRECONFIG option?
>>     
>
> It appears in __check_pf() getifaddrs() returned inconsistent data:
>
>   


Thanks to all who responded - of course several folks pointed out that 
the issue is already fixed in svn uclibc, but for some reason it didn't 
make it into uclibc 0.9.30.1

http://lists.uclibc.org/pipermail/uclibc-cvs/2008-December/025767.html

Is there any chance this could please be considered for inclusion in the next release?



Gentoo bug filed here:
http://bugs.gentoo.org/show_bug.cgi?id=278610

Thanks

Ed W

[-- Attachment #2: Type: text/html, Size: 1480 bytes --]