On Mon, Mar 11, 2013 at 05:58:54PM -0400, Saul Waizer wrote:
> Thanks Willy,
>
> Here is the strace (constantly showing the same output very fast!) I will
> try the snapshot and post my findings, let me know your thoughts on the
> strace
>
>
> strace -tt -p 13659
> Process 13659 attached - interrupt to quit
> 17:56:26.908085 epoll_wait(0, {{EPOLLHUP, {u32=4, u64=4}}}, 7, 1000) = 1
> 17:56:26.908300 gettimeofday({1363038986, 908332}, NULL) = 0
> 17:56:26.908378 accept(4, 0x7fff0e2118c0, [5854207880927903872]) = -1
> EINVAL (Invalid argument)
Wow! The last arg you're seeing above is the address size... And
if you look at it in hex, you get this :
$ printf "%16x\n" 5854207880927903872
513e530d00000080
The lowest 32 bits are 0x80 = 128, which is what I'm getting here. So
it looks like either your kernel or your libc is bogus and considers
there is an integer here instead of a socklen_t. Here's what I'm getting
here :
accept(4, 0x7fff408f9450, [128]) = -1 EAGAIN (Resource temporarily
unavailable)
The offending code does this :
struct sockaddr_storage addr;
socklen_t laddr = sizeof(addr);
if ((cfd = accept(fd, (struct sockaddr *)&addr, &laddr)) == -1)
{
As you can see, there is no way for laddr to be wrong. I'm still suspecting
an incorrect libc (eg: built with socklen_t = int instead of long). Is this
a standard maintained distro system or a home-made one (eg: LFS etc...) ?
Anyway, the fact that it fails on this system and not on other ones could be
precisely caused by a different kernel+libc combination.
Just in case, please take the executable from another working system and try
again. If it works, then it means that your .h are wrong. If it still fails,
it could be the libc.so.
You should probably try to build it again from clean sources, just in case...
Regards,
Willy
