[Top][All Lists]

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

Re: test-getcwd-lgpl fails on FreeBSD 8.1

From: Eric Blake
Subject: Re: test-getcwd-lgpl fails on FreeBSD 8.1
Date: Fri, 13 May 2011 10:11:55 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.10

On 05/13/2011 02:26 AM, Matthias Bolte wrote:
> I found this while testing current libvirt git on FreeBSD 8.1 32bit.
> When running gmake check in the libvirt source tree then ASSERT
> (getcwd (NULL, i) == NULL) in test-getcwd-lgpl.c in line 74 fails on
> the first iteration of the for loop.

Thanks for the report.  Apparently, FreeBSD behaves like mingw in that
getcwd(NULL, too_small_nonzero) allocates a larger size rather than
doing the glibc behavior of failing with ERANGE; technically, this is
both allowed by POSIX and makes sense (no need to cripple the system
getcwd to fail in that case, since the end result would be the user
having to re-call getcwd with a larger requested buffer size anyway).
Mingw getcwd has to be replaced for other reasons (wrong signature), but
I believe that if this were the only issue, then the best fix here is to
change the unit test to allow FreeBSD and mingw behavior.

However, I see a converse problem.  On glibc, getcwd(NULL, too_large)
malloc's too_large bytes, and does not realloc to shrink it (only size 0
causes the realloc path).  But on FreeBSD,


the allocation is blindly started at PATH_MAX bytes and never shrunk.
But that means that if too_large is bigger than PATH_MAX, and the
program blindly relies on glibc semantics for that many bytes to be
allocated and thus references into the end of the array assuming a
bigger-than-necessary array was allocated, then we have an out-of-bounds
reference.  The FreeBSD behavior would be detectable at configure time
by doing:

getcwd(NULL, SIZE_MAX-1)

which fails with ENOMEM on glibc (the malloc(SIZE_MAX-1) is too huge)
but generally succeeds on FreeBSD (which blindly sets size to PATH_MAX
for its starting iteration, ignoring the user's hint).

That said, this seems like fringe coding (how many programs do you know
that use getcwd(NULL, 1024*1024) instead of malloc(1024*1024) to
guarantee a 1MiB buffer?).  So for now, I'll just document that gnulib
does _not_ fix that portability hole, while updating the test.

> When runnig in gdb
> ./gnulib/tests/test-getcwd-lgpl in the libvirt source tree then the
> same ASSERT fails. Sometimes ASSERT (chdir (pwd1) == 0) in
> test-getcwd-lgpl.c in line 51 fails too, but I'm not able to reproduce
> this one reliably.

I have not reproduced this one either.  Is it only when running in gdb?
 Then maybe that's a gdb bug?

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]