patch, 2 partsfix a segfault in get_main_ref_store()

I stumbled across a BUG() today. But interestingly, in the current tip of master it actually segfaults instead! This fixes the segfault (back into a BUG(), and then fixes the caller to avoid the BUG() in the first place).

  [1/2]: get_main_ref_store: BUG() when outside a repository
  [2/2]: config: die when --blob is used outside a repository

 builtin/config.c       | 3 +++
 refs.c                 | 3 +++
 t/t1307-config-blob.sh | 4 ++++
 3 files changed, 10 insertions(+)

-Peff

If we don't have a repository, then we can't initialize the ref store. Prior to 64a741619d (refs: store the main ref store inside the repository struct, 2018-04-11), we'd try to access get_git_dir(), and outside a repository that would trigger a BUG(). After that commit, though, we directly use the_repository->git_dir; if it's NULL we'll just segfault.

Let's catch this case and restore the BUG() behavior. Obviously we don't ever want to hit this code, but a BUG() is a lot more helpful than a segfault if we do.

Signed-off-by: Jeff King <peff@peff.net>
---
 refs.c | 3 +++
 1 file changed, 3 insertions(+)

On Fri, May 18, 2018 at 3:25 PM, Jeff King <peff@peff.net> wrote:

That is true and an immediate bandaid; an alternative would be to do:

  if (!r->gitdir)
    /* not in a git directory ? */
    return NULL;
    /* We signal the caller the absence of a git repo by NULL ness
      of the ref store */

However that we would need to catch at all callers of get_main_ref_store and error out accordingly.

Then the trade off would be, how many callers to the main ref store do we have compared to options that rely on a ref store present? (I assume a patch like the second patch would show up in more cases now for all BUGs that we discover via this patch. The tradeoff is just if we want to report all these early by checking the config and system state, or wait until we get NULL ref store and then bail)

I think checking early makes sense; I am not so sure about this patch; for the time being it makes sense, though in the long run, we rather want to catch this at a higher level:

r->gitdir is supposedly never NULL, so we shall not produce this state. Maybe we want to set the_repository to NULL if set_git_dir fails (via repo_set_gitdir in setup_git_env, which both return void today).

Enough of my rambling, the patches look good! Stefan

If you run "config --blob" outside of a repository, then we eventually try to resolve the blob name and hit a BUG(). Let's catch this earlier and provide a useful message.

Note that we could also catch this much lower in the stack, in git_config_from_blob_ref(). That might cover other callsites, too, but it's unclear whether those ones would actually be bugs or not. So let's leave the low-level functions to assume the caller knows what it's doing (and BUG() if it turns out it doesn't).

Signed-off-by: Jeff King <peff@peff.net>
---
 builtin/config.c       | 3 +++
 t/t1307-config-blob.sh | 4 ++++
 2 files changed, 7 insertions(+)

On Fri, May 18, 2018 at 03:27:04PM -0700, Jeff King wrote:

I think that this approach is sensible. Let's (1) fix a SIGSEGV that should be a BUG(), and (2) make sure that we never get there in the first place.

This looks fine to me.

Thanks, Taylor

Hi Peff,

On Fri, 18 May 2018, Jeff King wrote:

Both patches look obviously correct to me.

Thanks, Dscho