This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Alexander.Belopolsky
Recipients Alexander.Belopolsky, l0nwlf, loewis, michael.foord, orsenthil, r.david.murray, ronaldoussoren
Date 2010-02-23.15:24:06
SpamBayes Score 1.2906347e-08
Marked as misclassified No
Message-id <d38f5331002230724j5836f8e9p251f26216efa93d2@mail.gmail.com>
In-reply-to <1266932795.31.0.207724978264.issue7900@psf.upfronthosting.co.za>
Content
On Tue, Feb 23, 2010 at 8:46 AM, Ronald Oussoren <report@bugs.python.org> wrote:
> ..
> I get test failures, but no crashes, when I do run the additional tests.

The crash that I see is apparently due to underallocated  memory:

 alt_grouplist = PyMem_Malloc(n);

should be

 alt_grouplist = PyMem_Malloc(n * sizeof(gid_t));

..
> I'm not too thrilled about your approach of growing the grouplist argument of
> getgroups until the results fit, the comment in the coreutils sources refers to two > very old unix flavors and IMHO it is not worthwhile to try to support those.
>

You are probably right on this point, but the main issue with using
getgroups(0, ..) is the race condition that it introduces.  If another
thread adds a group between n = getgroups(0, ..) and getgroups(n, ..)
calls, the second call will fail.

Makes sense regardless of the approach.
History
Date User Action Args
2010-02-23 15:24:08Alexander.Belopolskysetrecipients: + Alexander.Belopolsky, loewis, ronaldoussoren, orsenthil, r.david.murray, michael.foord, l0nwlf
2010-02-23 15:24:07Alexander.Belopolskylinkissue7900 messages
2010-02-23 15:24:06Alexander.Belopolskycreate