Well, there is a memory dump when you cause a segfault in NodeGit or libgit2. It comes in the form of disassembly, though, so if you are not keen on parsing through pointer information they don't often help much. You can glean some info from them, however.

As for your concern, we generate errors directly from libgit2, so the error you see is simply the returned error code and error message from the libgit2 routine that we invoked via NodeGit. There isn't really a "stack trace" as you know it. You run one method at a time from NodeGit, so if you get an error you should be able to deduce where it is coming from with a little work.

That is all of the information we receive back from libgit2 so there isn't much else we can give you.

If you want to try and get a stack trace yourself, you can try using something like this to manually grab a trace from libgit2. Although, I have never done that so I cannot speak for its effectiveness.

I think the issue here is that it's not at all obvious where the error is coming from in a long promise chain given the (mostly) asynchronous nature of NodeGit.

If libgit2 doesn't provide a stack trace of C functions, can NodeGit not provide a stack trace of JavaScript functions?

We might be able to add some code to our generators to, at the very least, return what routine threw the error. I would need to look at the code that generates the async functions again, but I feel like that minimal solution might not be too bad to implement. What do you think of something like appending the function name to the error as some property, like err.errorFunction? I don't want to call it a stack, because it isn't. @implausible any thoughts?

Yeah that "solution" has been a verbally discussed intent for a long time, just nobody ever had time to get to it. Super useful though, most likely, even if just to aid in bug reporting or requesting help more than in direct debugging.

Maybe if I get time this weekend I will draft something up. It would be helpful, I agree.

@cjhoward92 For the function's name, what are you thinking of? The libgit2 C function like git_merge_base or the generated C++ function like Merge::base?

The name of the function you call from NodeGit. So Merge::base more likely than not.

That seems more logical to me, as we want this for debugging in JavaScript

I've submitted pull request #1393 which adds a new errorFunction property to the error with a value of Merge.base (as an example) to match the JavaScript function's name.

Merged

I'll leave it in here In case anyone has this problem.

To fix stacktraces I created this function:

export async function wrapError<T>(asyncFunc: () => T): Promise<T> {
  try {
    return await asyncFunc();
  } catch (errMsg) {
    if (errMsg && errMsg.errorFunction) {
      const err = new Error(errMsg.message);
      const stackList = err.stack.split('\n');
      err.stack = stackList.slice(0, 1).concat(stackList.slice(3)).join('\n');
      for (const k in errMsg) {
        err[k] = errMsg[k];
      }
      throw err;
    }
    throw errMsg;
  }
}

Then I wrap every nodegit call with it.

await wrapError(async () => await Repository.open(this.rootPath));

A bit hacky but this way I'm getting nice error messages:

Error: no reference found for shorthand 'refs/remotes/origin/xmain'
    at async GitScanner.pullBranch (file:///home/gg/workspaces/mieweb/wikiGDrive/src/git/GitScanner.ts:162:28)
    at async Context.<anonymous> (file:///home/gg/workspaces/mieweb/wikiGDrive/test/git/RebaseTest.ts:285:7)