Message99926
| 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. |
|