From: "Torsten Bögershausen" <tboegi@web.de>
To: kusmabite@gmail.com, Junio C Hamano <gitster@pobox.com>
Cc: Filipe Cabecinhas <filcab@gmail.com>,
GIT Mailing-list <git@vger.kernel.org>,
msysGit <msysgit@googlegroups.com>
Subject: Re: write() _will_ fail on Mac OS X/XNU if nbytes > INT_MAX
Date: Wed, 20 Nov 2013 14:03:20 +0100 [thread overview]
Message-ID: <528CB318.1070201@web.de> (raw)
In-Reply-To: <CABPQNSaWTMCeCCnxkRV-Cri7-iQrRknHfJvvN_2Rs9V51OS81w@mail.gmail.com>
Hej,
I think the patch went in and out in git.git, please see below.
(I coudn't the following in msysgit,
but if it was there, the clipped_write() for Windows could go away.
/Torsten
commit 0b6806b9e45c659d25b87fb5713c920a3081eac8
Author: Steffen Prohaska <prohaska@zib.de>
Date: Tue Aug 20 08:43:54 2013 +0200
xread, xwrite: limit size of IO to 8MB
Checking out 2GB or more through an external filter (see test) fails
on Mac OS X 10.8.4 (12E55) for a 64-bit executable with:
error: read from external filter cat failed
error: cannot feed the input to external filter cat
error: cat died of signal 13
error: external filter cat failed 141
error: external filter cat failed
The reason is that read() immediately returns with EINVAL when asked
to read more than 2GB. According to POSIX [1], if the value of
nbyte passed to read() is greater than SSIZE_MAX, the result is
implementation-defined. The write function has the same restriction
[2]. Since OS X still supports running 32-bit executables, the
32-bit limit (SSIZE_MAX = INT_MAX = 2GB - 1) seems to be also
imposed on 64-bit executables under certain conditions. For write,
the problem has been addressed earlier [6c642a].
Address the problem for read() and write() differently, by limiting
size of IO chunks unconditionally on all platforms in xread() and
xwrite(). Large chunks only cause problems, like causing latencies
when killing the process, even if OS X was not buggy. Doing IO in
reasonably sized smaller chunks should have no negative impact on
performance.
The compat wrapper clipped_write() introduced earlier [6c642a] is
not needed anymore. It will be reverted in a separate commit. The
new test catches read and write problems.
Note that 'git add' exits with 0 even if it prints filtering errors
to stderr. The test, therefore, checks stderr. 'git add' should
probably be changed (sometime in another commit) to exit with
nonzero if filtering fails. The test could then be changed to use
test_must_fail.
On 2013-11-20 11.15, Erik Faye-Lund wrote:
> I know I'm extremely late to the party, and this patch has already
> landed, but...
>
> On Sat, May 11, 2013 at 1:05 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Filipe Cabecinhas <filcab@gmail.com> writes:
>>
>>> Due to a bug in the Darwin kernel, write() calls have a maximum size of
>>> INT_MAX bytes.
>>>
>>> This patch introduces a new compat function: clipped_write
>>> This function behaves the same as write() but will write, at most, INT_MAX
>>> characters.
>>> It may be necessary to include this function on Windows, too.
>
> We are already doing something similar for Windows in mingw_write (see
> compat/mingw.c), but with a much smaller size.
>
> It feels a bit pointless to duplicate this logic.
>
>> diff --git a/compat/clipped-write.c b/compat/clipped-write.c
>> new file mode 100644
>> index 0000000..9183698
>> --- /dev/null
>> +++ b/compat/clipped-write.c
>> @@ -0,0 +1,13 @@
>> +#include <limits.h>
>> +#include <unistd.h>
>> +
>> +/*
>> + * Version of write that will write at most INT_MAX bytes.
>> + * Workaround a xnu bug on Mac OS X
>> + */
>> +ssize_t clipped_write(int fildes, const void *buf, size_t nbyte)
>> +{
>> + if (nbyte > INT_MAX)
>> + nbyte = INT_MAX;
>> + return write(fildes, buf, nbyte);
>> +}
>
> If we were to reuse this logic with Windows, we'd need to have some
> way of overriding the max-size of the write.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
prev parent reply other threads:[~2013-11-20 13:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-09 22:31 write() _will_ fail on Mac OS X/XNU if nbytes > INT_MAX Filipe Cabecinhas
2013-04-09 22:50 ` Junio C Hamano
2013-05-09 22:58 ` Filipe Cabecinhas
2013-05-10 2:28 ` Junio C Hamano
2013-05-10 22:24 ` Filipe Cabecinhas
2013-05-10 23:05 ` Junio C Hamano
2013-05-10 23:10 ` Junio C Hamano
2013-05-10 23:13 ` Filipe Cabecinhas
2013-05-10 23:19 ` Filipe Cabecinhas
2013-05-10 23:36 ` Junio C Hamano
2013-11-20 10:15 ` Erik Faye-Lund
2013-11-20 13:03 ` Torsten Bögershausen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=528CB318.1070201@web.de \
--to=tboegi@web.de \
--cc=filcab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kusmabite@gmail.com \
--cc=msysgit@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).