Bug 7408 - Server can't listen and crashes on PPC Linkstation Linux because AI_ADDRCONFIG fails
Server can't listen and crashes on PPC Linkstation Linux because AI_ADDRCONFI...
Product: Samba 3.5
Classification: Unclassified
Component: File services
PPC Linux
: P3 critical
: ---
Assigned To: Volker Lendecke
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2010-05-04 04:11 UTC by Andrei Remenchuk
Modified: 2010-11-04 12:37 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Andrei Remenchuk 2010-05-04 04:11:34 UTC
Both smbd and nmbd crash right after launch on PPC Linux 2.4 after failing to bind to any socket. Excerpt from log is provided below.

The system identifies as Linux 2.4.20_mvl31-ppc_linkstation. 

The problem is ultimately caused by networking code using AI_ADDRCONFIG flag, which is defined, but causes getaddrinfo() to fail when used.
Previous working version of Samba (3.0.28) didn't have this problem. 

#undefining AI_ADDRCONFIG did help. 

Log (smbd -i -d9):
interpret_string_addr_internal: getaddrinfo failed for name [Bad value for ai_flags]
open_sockets_smbd: No sockets available to bind to.
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
NT user token: (NULL)
UNIX token of user 0
Primary group is 0 and contains 0 supplementary groups
change_to_root_user: now uid=(0,0) gid=(0,0)
Yielding connection to 
deleting connection record returned NT_STATUS_NOT_FOUND
Abnormal server exit: open_sockets_smbd() failed
BACKTRACE: 5 stack frames:
 #0 ./bin/smbd(log_stack_trace+0x44) [0x10316f5c]
 #1 ./bin/smbd [0x10656a18]
 #2 ./bin/smbd(exit_server_cleanly+0) [0x10655840]
 #3 ./bin/smbd(main+0x690) [0x10655f18]
 #4 /lib/libc.so.6(__libc_start_main+0x178) [0xfd52148]
dumping core in /usr/local/samba/var/cores/smbd
Aborted (core dumped)

Test program which demonstrates the problem with AI_ADDRCONFIG
#include <stdio.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <netinet/tcp.h>
#include <netinet/ip.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

int main(int argc, char** argv)
    int ret;
    struct addrinfo hints;
    struct addrinfo *ppres = NULL;
    const char* hostname = "";

    memset(&hints, '\0', sizeof(hints));
    hints.ai_socktype = SOCK_STREAM;
    hints.ai_family = AF_INET;
    hints.ai_flags = AI_ADDRCONFIG;
    ret = getaddrinfo(hostname, NULL, &hints, &ppres);
    if (ret != 0) 
    	fprintf(stderr, "getaddrinfo('%s'), flags=0x%08x failed. return value=%d; errno=%d\n", hostname, hints.ai_flags, ret, errno);
    return ret;

It fails on this system:
getaddrinfo(''), flags=0x00000020 failed. return value=-1; errno=0
Comment 1 Jeremy Allison 2010-05-04 17:41:30 UTC
I'm not sure what we can do here - isn't this a platform problem ?

Can you undef AI_ADDRCONFIG and re-define it as zero for your build on this platform ?

Comment 2 Andrei Remenchuk 2010-05-04 18:01:48 UTC
This does seem to be a platform problem. I #undefed AI_ADDRCONFIG in lib/replace/system/network.h and that helped. 

This same problem also was reported for at least two other platforms - QNX (https://bugzilla.samba.org/show_bug.cgi?id=6630) and AIX (https://bugzilla.samba.org/show_bug.cgi?id=5910). 

This is already fixed for QNX in lib/replace/system/network.h. That particular fix relies on OS-specific macros, however Linkstation environment can't be identified that way.

Perhaps conf test to determine if AI_ADDRCONFIG actually works would be a better solution for this and for 5910. 

Comment 3 Volker Lendecke 2010-05-10 06:58:13 UTC
Reducing severity from blocker to critical. Yes, this does block you, but I think we should not block a whole release that works fine for many platforms due to problems on a niche system.

We need to follow up on this though soon.


Comment 4 Kai Blin 2010-05-10 07:02:17 UTC
It would be interesting to see if this is a generic problem of Linux 2.4, or at least of Linux 2.4 on PPC. I wonder if it can be reproduced under an emulator (don't have a PPC system around to play with)
Comment 5 Volker Lendecke 2010-05-10 07:52:43 UTC
Generic 2.4 should be pretty easy to test.

Kai, what about that you confirm this is / is not a generic 2.4 problem? :-)

Comment 6 Kai Blin 2010-05-10 09:13:11 UTC
Seems to work on a Debian Sarge install on x86 with a 2.4.27 kernel.
Comment 7 Volker Lendecke 2010-11-04 12:37:04 UTC
Fixed with 6e7bcaa8 in v3-6-test.