Skip to content
This repository has been archived by the owner on Nov 9, 2017. It is now read-only.

Added the --large-address-aware linker directive to the makefile. #12

Closed
wants to merge 1 commit into from

Conversation

pleriche
Copy link

This has the effect of increasing the address space from 2GB to 4GB under 64-bit Windows, reducing the likelihood of an "out of memory" error when e.g. repacking a large repository.
All tests in the "devel" branch (as at 27/5/2012) pass with this patch in place.

@buildhive
Copy link

MSysGit - the development behind Git for Windows » git #3 FAILURE
Looks like there's a problem with this pull request
(what's this?)

@kusma
Copy link
Member

kusma commented May 27, 2012

LDFLAGS should probably be modified in the Windows-specific parts of the makefile to avoid breaking the BuildHive builds. Search for "MINGW" to find the right place.

@dscho
Copy link
Member

dscho commented May 28, 2012

Ooops. Sorry @kusma, I said earlier that it was @hvoigt who mentioned that BuildHive is not happy...

@pleriche: I added an inline comment that should be helpful enough to finalize this pull request.

@pleriche
Copy link
Author

Thanks all for your assistance. I've pushed a new patch that should only affect MinGW build.

@buildhive
Copy link

MSysGit - the development behind Git for Windows » git #4 FAILURE
Looks like there's a problem with this pull request
(what's this?)

@pleriche
Copy link
Author

The BuildHive is still complaining :(. I've pasted the output error below. Unfortunately it doesn't give a novice like me enough information to work on.

make[1]: Target aggregate-results-and-cleanup' not remade because of errors. make[1]: Leaving directory/scratch/hudson/workspace/msysgit/git/t'
make: *** [test] Error 2
make: Target all' not remade because of errors. make: Leaving directory/scratch/hudson/workspace/msysgit/git/t'
Build step 'Execute shell' marked build as failure

@patthoyts
Copy link
Member

That failure report is a problem with the buildhive test script and not caused by your patch. I've checked out and built your pleriche/devel branch on a linux box and it builds and tests fine. It builds fine on Windows as well and assuming the test completes ok I'll merge it shortly.

@patthoyts
Copy link
Member

I've reformatted the commit message and was adding a Signed-off-by as you didn't do that - your commit has the user.email part as 'Pierre le Riche github@pleasedontspam.me' - is that what you want to keep? Typically these are reachable addresses and we just let spam filters deal with the spam.

@pleriche
Copy link
Author

@patthoyts Thanks for testing my patch. That e-mail address is a valid address. I've found that having a domain with "spam" in the name works remarkably well as a spam countermeasure. I attribute that to spammers and their address harvesting bots assuming it's a fake address.

This has the effect of increasing the address space from 2GB to 4GB under 64-bit Windows, reducing the likelihood of an "out of memory" error when e.g. repacking a large repository.  The test suite passes with this patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc calls.  While this is no guarantee that there are no issues with large memory support (it could break Git on other setups than mine, for example), it at least increases the chance that nothing obvious goes wrong (such as errors introduced by faulty sign extension, say, with ssize_t).

Signed-off-by: Pierre le Riche <github@pleasedontspam.me>
@buildhive
Copy link

MSysGit - the development behind Git for Windows » git #7 FAILURE
Looks like there's a problem with this pull request
(what's this?)

patthoyts pushed a commit that referenced this pull request May 28, 2012
This has the effect of increasing the address space from 2GB to 4GB under
64-bit Windows, reducing the likelihood of an "out of memory" error when e.g.
repacking a large repository.  The test suite passes with this patch, with and
without the MEM_TOP_DOWN flag added to all VirtualAlloc calls.  While this is
no guarantee that there are no issues with large memory support (it could break
Git on other setups than mine, for example), it at least increases the chance
that nothing obvious goes wrong (such as errors introduced by faulty sign
extension, say, with ssize_t).

[PT: Resolves github issue #12]

Signed-off-by: Pierre le Riche <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
@patthoyts patthoyts closed this May 28, 2012
dscho pushed a commit that referenced this pull request May 29, 2012
…e makefile.

Use this commit message, rewrapped to 76 columns:
msysgit: Add the --large-address-aware linker directive to the makefile.

This has the effect of increasing the address space from 2GB to 4GB under
64-bit Windows, reducing the likelihood of an "out of memory" error when
e.g.  repacking a large repository.  The test suite passes with this
patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc
calls.  While this is no guarantee that there are no issues with large
memory support (it could break Git on other setups than mine, for
example), it at least increases the chance that nothing obvious goes wrong
(such as errors introduced by faulty sign extension, say, with ssize_t).

[PT: Resolves github issue #12]

Signed-off-by: Pierre le Riche <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
dscho pushed a commit that referenced this pull request May 29, 2012
This has the effect of increasing the address space from 2GB to 4GB under
64-bit Windows, reducing the likelihood of an "out of memory" error when
e.g.  repacking a large repository.  The test suite passes with this
patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc
calls.  While this is no guarantee that there are no issues with large
memory support (it could break Git on other setups than mine, for
example), it at least increases the chance that nothing obvious goes wrong
(such as errors introduced by faulty sign extension, say, with ssize_t).

[PT: Resolves github issue #12]

Signed-off-by: Pierre le Riche <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
@dscho
Copy link
Member

dscho commented May 29, 2012

FWIW to find the real error in BuildHive, look at the complete logs and search for "# failed ". I also re-reformatted the commit message to <=76 columns/line.

dscho pushed a commit that referenced this pull request Jun 5, 2012
This has the effect of increasing the address space from 2GB to 4GB under
64-bit Windows, reducing the likelihood of an "out of memory" error when
e.g.  repacking a large repository.  The test suite passes with this
patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc
calls.  While this is no guarantee that there are no issues with large
memory support (it could break Git on other setups than mine, for
example), it at least increases the chance that nothing obvious goes wrong
(such as errors introduced by faulty sign extension, say, with ssize_t).

[PT: Resolves github issue #12]

Signed-off-by: Pierre le Riche <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
patthoyts pushed a commit that referenced this pull request Jun 20, 2012
This has the effect of increasing the address space from 2GB to 4GB under
64-bit Windows, reducing the likelihood of an "out of memory" error when
e.g.  repacking a large repository.  The test suite passes with this
patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc
calls.  While this is no guarantee that there are no issues with large
memory support (it could break Git on other setups than mine, for
example), it at least increases the chance that nothing obvious goes wrong
(such as errors introduced by faulty sign extension, say, with ssize_t).

[PT: Resolves github issue #12]

Signed-off-by: Pierre le Riche <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
patthoyts pushed a commit that referenced this pull request Oct 2, 2012
This has the effect of increasing the address space from 2GB to 4GB under
64-bit Windows, reducing the likelihood of an "out of memory" error when
e.g.  repacking a large repository.  The test suite passes with this
patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc
calls.  While this is no guarantee that there are no issues with large
memory support (it could break Git on other setups than mine, for
example), it at least increases the chance that nothing obvious goes wrong
(such as errors introduced by faulty sign extension, say, with ssize_t).

[PT: Resolves github issue #12]

Signed-off-by: Pierre le Riche <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
patthoyts pushed a commit that referenced this pull request Oct 23, 2012
This has the effect of increasing the address space from 2GB to 4GB under
64-bit Windows, reducing the likelihood of an "out of memory" error when
e.g.  repacking a large repository.  The test suite passes with this
patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc
calls.  While this is no guarantee that there are no issues with large
memory support (it could break Git on other setups than mine, for
example), it at least increases the chance that nothing obvious goes wrong
(such as errors introduced by faulty sign extension, say, with ssize_t).

[PT: Resolves github issue #12]

Signed-off-by: Pierre le Riche <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
dscho pushed a commit that referenced this pull request Dec 3, 2012
This has the effect of increasing the address space from 2GB to 4GB under
64-bit Windows, reducing the likelihood of an "out of memory" error when
e.g.  repacking a large repository.  The test suite passes with this
patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc
calls.  While this is no guarantee that there are no issues with large
memory support (it could break Git on other setups than mine, for
example), it at least increases the chance that nothing obvious goes wrong
(such as errors introduced by faulty sign extension, say, with ssize_t).

[PT: Resolves github issue #12]

Signed-off-by: Pierre le Riche <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
kusma pushed a commit that referenced this pull request Jan 4, 2013
This has the effect of increasing the address space from 2GB to 4GB under
64-bit Windows, reducing the likelihood of an "out of memory" error when
e.g.  repacking a large repository.  The test suite passes with this
patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc
calls.  While this is no guarantee that there are no issues with large
memory support (it could break Git on other setups than mine, for
example), it at least increases the chance that nothing obvious goes wrong
(such as errors introduced by faulty sign extension, say, with ssize_t).

[PT: Resolves github issue #12]

Signed-off-by: Pierre le Riche <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
patthoyts pushed a commit that referenced this pull request Jan 16, 2013
This has the effect of increasing the address space from 2GB to 4GB under
64-bit Windows, reducing the likelihood of an "out of memory" error when
e.g.  repacking a large repository.  The test suite passes with this
patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc
calls.  While this is no guarantee that there are no issues with large
memory support (it could break Git on other setups than mine, for
example), it at least increases the chance that nothing obvious goes wrong
(such as errors introduced by faulty sign extension, say, with ssize_t).

[PT: Resolves github issue #12]

Signed-off-by: Pierre le Riche <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
patthoyts pushed a commit that referenced this pull request Feb 1, 2013
This has the effect of increasing the address space from 2GB to 4GB under
64-bit Windows, reducing the likelihood of an "out of memory" error when
e.g.  repacking a large repository.  The test suite passes with this
patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc
calls.  While this is no guarantee that there are no issues with large
memory support (it could break Git on other setups than mine, for
example), it at least increases the chance that nothing obvious goes wrong
(such as errors introduced by faulty sign extension, say, with ssize_t).

[PT: Resolves github issue #12]

Signed-off-by: Pierre le Riche <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
patthoyts pushed a commit that referenced this pull request May 25, 2013
This has the effect of increasing the address space from 2GB to 4GB under
64-bit Windows, reducing the likelihood of an "out of memory" error when
e.g.  repacking a large repository.  The test suite passes with this
patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc
calls.  While this is no guarantee that there are no issues with large
memory support (it could break Git on other setups than mine, for
example), it at least increases the chance that nothing obvious goes wrong
(such as errors introduced by faulty sign extension, say, with ssize_t).

[PT: Resolves github issue #12]

Signed-off-by: Pierre le Riche <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
patthoyts pushed a commit that referenced this pull request Jun 7, 2013
This has the effect of increasing the address space from 2GB to 4GB under
64-bit Windows, reducing the likelihood of an "out of memory" error when
e.g.  repacking a large repository.  The test suite passes with this
patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc
calls.  While this is no guarantee that there are no issues with large
memory support (it could break Git on other setups than mine, for
example), it at least increases the chance that nothing obvious goes wrong
(such as errors introduced by faulty sign extension, say, with ssize_t).

[PT: Resolves github issue #12]

Signed-off-by: Pierre le Riche <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
dscho referenced this pull request in dscho/git Aug 26, 2017
Since commit 612c49e ("credential-cache: add tests for XDG
functionality", 17-03-2017), the cygwin build has been failing all the
new tests added by that commit. In particular, the 'git credential-cache
exit' command, as part of the test cleanup code, has been die-ing with
the message:

    fatal: read error from cache daemon: Connection reset by peer

As this git command is part of an && chain in a 'test_when_finished'
call, the remaining test cleanup is not happening, so practically all
remaining tests fail due to the unexpected presence of various socket
files and directories.

A simple means of getting the tests to pass, is to simply ignore the
failure of 'git credential-cache exit' command and make sure all test
cleanup is done. For example, the diff for test #12 would look like:

    diff --git a/t/t0301-credential-cache.sh b/t/t0301-credential-cache.sh
    index fd92533ac..87e5001bb 100755
    --- a/t/t0301-credential-cache.sh
    +++ b/t/t0301-credential-cache.sh
    @@ -17,7 +17,7 @@ helper_test cache

     test_expect_success 'socket defaults to ~/.cache/git/credential/socket' '
            test_when_finished "
    -               git credential-cache exit &&
    +               (git credential-cache exit || :) &&
                    rmdir -p .cache/git/credential/
            " &&
            test_path_is_missing "$HOME/.git-credential-cache" &&

... and so on for all remaining tests. While this does indeed make all
tests pass, it is not really a solution.

As an aside, while looking to debug this issue, I added the '--debug'
option to the invocation of the 'git-credential-cache--daemon' child
process (see the spawn_daemon() function). This not only fixed the tests,
but also stopped git-credential-cache exiting with a failure. Since the
only effect of passing '--debug' was to suppress the redirection of stderr
to the bit-bucket (/dev/null), I have no idea why this seems to fix the
protocol interaction between git and git-credential-cache--daemon. (I
did think that maybe it was a timing issue, so I tried sleeping before
reading from the daemon on Linux, but that only slowed down the tests!)

All descriptions of the "Connection reset by peer" error, that I could
find, say that the peer had destroyed the connection before the client
attempted to perform I/O on the connection. Since the daemon does not
respond to an "exit" message from the client, it just closes the socket
and deletes the socket file (via the atexit handler), it seems that the
expected result is for the client to receive an EOF.  Indeed, this is
exactly what seems to be happening on Linux. Also a comment in
credential-cache--daemon.c reads:

    else if (!strcmp(action.buf, "exit")) {
            /*
             * It's important that we clean up our socket first, and then
             * signal the client only once we have finished the cleanup.
             * Calling exit() directly does this, because we clean up in
             * our atexit() handler, and then signal the client when our
             * process actually ends, which closes the socket and gives
             * them EOF.
             */
            exit(0);
    }

On cygwin this is not the case, at least when not passing --debug to the
daemon, and the read following the "exit" gets an error with errno set
to ECONNRESET.

In order to suppress the fatal exit in this case, check the read error
for an ECONNRESET and return as if no data was read from the daemon.
This effectively converts an ECONNRESET into an EOF.

Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants