Am 10.11.2012 22:13, schrieb Jean-Jacques Lafay:
Le samedi 10 novembre 2012 21:00:10 UTC+1, Philip Oakley a écrit :
November 10, 2012 5:36 PM
> In large repos, the recursion implementation of contains(commit,
> may result in a stack overflow. Replace the recursion with a loop to
> fix it.
> Signed-off-by: Jean-Jacques Lafay <jeanjacq...@gmail.com
This is a change to the main git code so it is better to submit it to
no HTML, first
post usually has a delay ;-)
It sounds reasonable but others may have opinions and comments.
Have you actually suffered from the stack overflow issue? You only
suggest it as a possibility, rather than a real problem.
Yes, it actually crashed on me, and since the call is made by
GitExtension while browsing the commit history, it was quickly annoying
to have windows popping a "git.exe stopped working" message box at my
face every time I clicked on a line of the history ;-) (well, you can
sort of work around it by having the "file tree" or "diff" tab active)
Coincidentally, as I was having a glance at the recent topics, I saw
that someone else experienced it.
However, I couldn't reproduce it on Linux : where the windows
implementations crashes at a ~32000 depth (*not* exactly 32768, mind
you), on linux it happily went through 100000 commits. I didn't take
time to look much further, but maybe on my 64 bit Linux VM, the process
can afford to reserve a much bigger address range for the stack of each
thread than the 1Mb given to 32 bit processes on windows.
I can reproduce it on Linux (Debian testing amd64) with ulimit -s 1000
to reduce the stack size from its default value of 8MB.
After reverting ffc4b8012d9a4f92ef238ff72c0d15e9e1b402ed (tag: speed up
--contains calculation) the test passes even with the smaller stack, but
it makes "git tag --contains" take thrice the time as before.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html