[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#816155: Assertion failure in gethostbyname



Package: libc6
Version: 2.21-9
User: debian-68k@lists.debian.org
Usertags: m68k

Hi,
Backstory: I maintain polyml, and was porting it to m68k; when running the test suite, I received an assertion failure in glibc in a call to gethostbyname.

It seems gethostbyname is broken, failing for me with “nss_files/files-hosts.c:218: _nss_files_gethostbyname3_r: Assertion `(bufferend - (char *) 0) % sizeof (char *) == 0' failed.” This can be reproduced with the following simple program:

    #include <stdio.h>
    #include <netdb.h>

    int main(int argc, char **argv) {
        struct hostent *h = gethostbyname("localhost");
        printf("name: %s\n", h->h_name);
        return 0;
    }

Delving inside glibc, _nss_files_gethostbyname3_r expects result->h_aliases to be aligned to sizeof(char *), as can be seen in the assert (bufferend points to an element in result->h_aliases, and each element is a char *). Provided this is true when the function is called, it seems to correctly maintain the invariant by rounding up bufferend when necessary.

However, the initial value of result->h_aliases is not aligned to sizeof(char *). Instead, it is assigned in parse_list (nss_files/files-parse.c:245) and aligned to __alignof__(char *). On many architectures, these are the same, but on m68k, __alignof__(char *) == 2, but sizeof(char *) == 4. There may be environments where result->h_aliases happens to be aligned to sizeof(char *) by chance, but that is most certainly not the case on mine (latest unstable running in ARAnyM).

I don’t know why bufferend is required to be aligned to sizeof(char *), and believe that imposing __alignof__(char *) in _nss_files_gethostbyname3_r instead would suffice. Alternatively, parse_list could choose MAX(sizeof(char *), __alignof__(char *)) as the alignment. Either way, the implementation as a whole is currently broken.

Regards,
James

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


Reply to: