Re: Further adventures in the land of 64-bit linux

I'm cc'ing Martin von Loewis, since I believe he checked in this
version of grpmodule.c.

[Anders Qvist]
> The next problem in the land of 64bit linux seems to be test_grp:
> 
>   [ 23:15 ] - ./python -u ../python/dist/src/Lib/test/regrtest.py -v -s
>   test_grp
>   test_getgrgid (test.test_grp.GroupDatabaseTestCase) ... zsh: segmentation fault  ./python -u
>   ../python/dist/src/Lib/test/regrtest.py -v -s
> 
> or, shorter:
> 
>   [ 23:18 ] - ./python -u
>   Python 2.3a0 (#3, Sep 12 2002, 19:11:35) 
>   [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
>   Type "help", "copyright", "credits" or "license" for more information.
>   >>> import grp
>   >>> g = grp.getgrall()
>   zsh: segmentation fault  ./python -u
> 
> or, in gdb:
> 
> >>> import grp
> >>> grp.getgrall()
> 
> Program received signal SIGSEGV, Segmentation fault.
> strlen () at ../sysdeps/alpha/strlen.S:45
> 45      ../sysdeps/alpha/strlen.S: Filen eller katalogen finns inte.
> Current language:  auto; currently asm
> (gdb) bt
> #0  strlen () at ../sysdeps/alpha/strlen.S:45
> #1  0x12004624c in PyString_FromString (str=0x0)
>     at ../python/dist/src/Objects/stringobject.c:111
> #2  0x20000d652ac in mkgrent (p=0x200008b31b0)
>     at /mp/slaskdisk/tmp/quest/python/dist/src/Modules/grpmodule.c:61
> #3  0x20000d653f8 in grp_getgrall (self=0x0, args=0x20000097325)
>     at /mp/slaskdisk/tmp/quest/python/dist/src/Modules/grpmodule.c:115
> #4  0x1200d9328 in PyCFunction_Call (func=0x20000093fd0, arg=0x20000025048, 
>     kw=0x0) at ../python/dist/src/Objects/methodobject.c:101
> #5  0x120082cb4 in call_function (pp_stack=0x11ffff530, oparg=619301)
>     at ../python/dist/src/Python/ceval.c:3228
> [...]
> 
> (gdb) frame 2
> #2  0x20000d652ac in mkgrent (p=0x200008b31b0)
>     at /mp/slaskdisk/tmp/quest/python/dist/src/Modules/grpmodule.c:61
> 61          SET(setIndex++, PyString_FromString(p->gr_passwd));
> Current language:  auto; currently c
> (gdb) print member
> $1 = (char **) 0x1202921b8
> (gdb) print p
> $2 = (struct group *) 0x200008b31b0
> (gdb) print p->gr_passwd
> $3 = 0x0
> (gdb) ptype p
> type = struct group {
>     char *gr_name;
>     char *gr_passwd;
>     __gid_t gr_gid;
>     char **gr_mem;
> } *
> (gdb) frame 1
> #1  0x12004624c in PyString_FromString (str=0x0)
>     at ../python/dist/src/Objects/stringobject.c:111
> 111             size = strlen(str);
> (gdb) list
> 106     {
> 107             register size_t size;
> 108             register PyStringObject *op;
> 109     
> 110             assert(str != NULL);
> 111             size = strlen(str);
> 112             if (size > INT_MAX) {
> 113                     PyErr_SetString(PyExc_OverflowError,
> 114                             "string is too long for a Python string");
> 115                     return NULL;
> 
> If I understand things correctly, this means that the previous line in
> stringobject.c (110) somehow fails to do its job, or we would have
> gotten an assert error. Is 0x0 NULL on linux/alpha?

Yes, NULL is 0x0 even on Linux/Alpha.

But Python is compiled with -DNDEBUG (unless you request a debug build
with "configure --with-pydebug") so the assert() is not executed.

I'm guessing that it's possible that the gr_passwd slot can be NULL on
that platform; the code doesn't expect this.

Martin?

--Guido van Rossum (home page: http://www.python.org/~guido/)