All of lore.kernel.org
 help / color / mirror / Atom feed
From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: Jeff King <peff@peff.net>
Cc: Erik Faye-Lund <kusmabite@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, j6t@kdbg.org
Subject: Re: [PATCH v2 4/4] upload-archive: use start_command instead of fork
Date: Mon, 01 Aug 2011 22:48:09 +0200	[thread overview]
Message-ID: <4E371109.7050500@lsrfire.ath.cx> (raw)
In-Reply-To: <20110801182516.GC10302@sigill.intra.peff.net>

Am 01.08.2011 20:25, schrieb Jeff King:
> On Mon, Aug 01, 2011 at 08:02:22PM +0200, Erik Faye-Lund wrote:
> 
>>> Weird. What does j.tgz end up looking like? Is it empty, or does it have
>>> bogus data in it? Does gzip actually get invoked at all? Try running
>>> with GIT_TRACE=1. I don't suppose you guys have something like strace,
>>> which might be helpful.
>>>
>>
>> It does have data, and gzip does get invoked:
>> $ gunzip -c j.tgz | wc -c
>>
>> gzip: j.tgz: invalid compressed data--format violated
>>  131072
>>
>> So it seems there are around 130k of valid data before it barfs.
>>
>> Hmm, but when I try the same after re-running the test, I get a
>> different amount of valid data (491520 bytes this time)... Is this a
>> timing-related issue?
> 
> Hmm. Non-deterministic output is not good. Could be timing, or we could
> be touching memory we're not supposed to. I just ran t5000 through
> valgrind, and nothing turned up. And of course I can't replicate the
> test failure on Linux. So I assume it really is Windows-specific.
> 
> That makes me suspect some difference in how the run-command API works
> on the two platforms, since that is the code here that will be vastly
> difference. I notice the start_command code uses dup() on Windows
> instead of dup2() (I guess you guys don't have dup2?). I wonder if there
> could be some issue with another descriptor accidentally pointing to the
> same spot. But that's just a wild guess.
> 
> I think at this point, I'd probably start stepping through the archive
> code with gdb.

Hrm, here is another data point, for what it's worth (Windows 7 x64,
MinGW):

	$ git archive v1.7.6 | gzip -cn | md5sum
	a0ca1c873a533a5fcd41d248fb325a5b *-

	$ git archive --format=tar.gz v1.7.6 | md5sum
	a0ca1c873a533a5fcd41d248fb325a5b *-

	$ git archive v1.7.6 | gzip -cn >a.tgz && md5sum <a.tgz
	a0ca1c873a533a5fcd41d248fb325a5b *-

	$ ls -l a.tgz
	-rw-r--r--    1 User     Administ  3361584 Aug  1 20:44 a.tgz

	$ git archive --format=tar.gz v1.7.6 >a.tgz && md5sum <a.tgz
	30886283af1aed05ae6a36fc5aeda077 *-

	$ ls -l a.tgz
	-rw-r--r--    1 User     Administ  3374383 Aug  1 20:45 a.tgz

	$ git archive --format=tar.gz v1.7.6 >a.tgz && md5sum <a.tgz
	30886283af1aed05ae6a36fc5aeda077 *-

	$ git archive --format=tar.gz v1.7.6 >a.tgz && md5sum <a.tgz
	30886283af1aed05ae6a36fc5aeda077 *-

	$ git archive v1.7.6 | gzip -cn >a.tgz && md5sum <a.tgz
	a0ca1c873a533a5fcd41d248fb325a5b *-

	$ git archive --format=tar.gz v1.7.6 | cat >a.tgz && md5sum <a.tgz
	a0ca1c873a533a5fcd41d248fb325a5b *-

	$ git archive -o a.tgz v1.7.6 && md5sum <a.tgz
	30886283af1aed05ae6a36fc5aeda077 *-

So git archive gives the right results when writing to a pipe, but
always the same wrong result when writing directly to a file.  With
--format=tar there is no difference:

	$ git archive v1.7.6 | md5sum
	fa364f38f9128df019dd8fd509c40a6d *-

	$ git archive v1.7.6 >a.tar && md5sum <a.tar
	fa364f38f9128df019dd8fd509c40a6d *-

René

  reply	other threads:[~2011-08-01 20:48 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-18 18:08 [PATCH v2 0/4] port upload-archive to Windows Erik Faye-Lund
2011-07-18 18:08 ` [PATCH v2 1/4] compat/win32/sys/poll.c: upgrade from upstream Erik Faye-Lund
2011-07-18 18:08 ` [PATCH v2 2/4] mingw: fix compilation of poll-emulation Erik Faye-Lund
2011-07-18 18:08 ` [PATCH v2 3/4] enter_repo: do not modify input Erik Faye-Lund
2011-07-18 18:08 ` [PATCH v2 4/4] upload-archive: use start_command instead of fork Erik Faye-Lund
2011-07-19 21:09   ` Junio C Hamano
2011-07-28  8:32     ` Erik Faye-Lund
2011-07-28 16:08       ` Jeff King
2011-07-28 16:47         ` Jeff King
2011-07-28 17:02           ` Jeff King
2011-08-01 14:45             ` Erik Faye-Lund
2011-08-01 17:46               ` Jeff King
2011-08-01 18:02                 ` Erik Faye-Lund
2011-08-01 18:25                   ` Jeff King
2011-08-01 20:48                     ` René Scharfe [this message]
2011-08-01 21:20                       ` Johannes Sixt
2011-08-01 21:42                         ` René Scharfe
2011-08-01 21:52                         ` René Scharfe
2011-08-02  4:00                           ` Jeff King
2011-08-02 16:46                             ` René Scharfe
2011-08-02 18:13                               ` Jeff King
2011-08-02 23:37                                 ` Johannes Sixt
2011-08-03  5:49                                   ` Jeff King
2011-08-06  9:40                                   ` René Scharfe
2011-08-07 20:02                                     ` Johannes Sixt
2011-08-07 21:06                                       ` Jeff King
2011-08-08 17:10                                       ` René Scharfe
2011-08-09  5:02                                         ` Jeff King
2011-08-09 10:25                                           ` René Scharfe
2011-08-09 20:05                                             ` Jeff King
2011-09-29 19:54                                               ` Erik Faye-Lund
2011-09-29 20:18                                                 ` René Scharfe
2011-09-29 20:20                                                   ` Erik Faye-Lund

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=4E371109.7050500@lsrfire.ath.cx \
    --to=rene.scharfe@lsrfire.ath.cx \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=kusmabite@gmail.com \
    --cc=peff@peff.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.