Re: git-daemon shallow checkout fail

[Bob Proulx <bob@proulx.com>]

Hello Johannes,

Thank you very much for the good hints here.  They are very helpful.

Johannes Schindelin wrote:
> Assuming that you can rebuild your Git with debug symbols and without
> optimization (simply remove the -O2 from CFLAGS in the Makefile, I never
> had any luck with single-stepping in gdb when compiled with -O2), you

I always debug with -g and without -O because otherwise it leads to a
lot of confusion.  But git-daemon is a forking daemon which makes
debugging it with the debugger somewhere more default and requiring
more setup to debug past the fork points.  As you note and hint with
later setting up an attach point for gdb.

> - that error message comes from shallow.c's setup_temporary_shallow()
>   function

Yes.  I find that too.

> - that function is only called from fetch-pack and receive-pack, neither
>   of which should be called by upload-pack, so it is a puzzle

The choice of directionality for upload and download might be
confusing me here too.  Since from the client side of things it is a
download.  But on the server side it is an upload.

> - adding a test case to t5570-git-daemon.sh that tests specifically your
>   described scenario seems *not* to fail:

I have seen some of the patches that seems like should have fixed this
problem.  It is perplexing.  But see my next mail on this too.

> - I even modified t/lib-git-daemon.sh to start the daemon as `nobody` and
>   kill it as `root`, and I won't share that patch because it is as
>   ugly, but *even then* the test succeeded.

It succeeds for me on other systems.  It is only the one (where I need
it) that it is failing.

> So my suspicion is that the repository you try to serve may already be
> shallow, or something else funky is going on that has not been included in
> your report.

It happens to any repository.  I picked a small repository and copied
it verbatim using rsync to my working environment.  The identical bits
of a repository copied by rsync work okay on one system but fail on
the other.

> The most direct way to get to the bottom of this may be to do something
> like this:
...
>  	if (write_shallow_commits(&sb, 0, extra)) {
> +error("About to create shallow_XXXXXX: pid = %d", getpid());
> +while (!debug_me) {
> +	sleep(1);
> +}
>  		fd = xmks_tempfile(&temporary_shallow, git_path("shallow_XXXXXX"));
>  
>  		if (write_in_full(fd, sb.buf, sb.len) != sb.len)
> -- snap --
> 
> Then let it run, wait for the error message "About to create
> shallow_XXXXXX" and then attach with a gdb started as nobody via `attach
> <pid>` to see the stack trace.
> 
> That should give you an idea where that code path is hit (unexpectedly).

That is a good hint.  I will give that a try.  However see my next
email for more (confusing) information.

Bob