How to interpret negative line number in stack trace

I made some changes to a fairly large project of mine today, and now I'm getting some odd behavior. Because I'm a knucklehead, I can't go back and figure out what I did.

But the main thrust of my question is how I should understand the negative line number in the stack trace that is printed. The -1218 below is the one that I mean.

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x1 pc=0x80501f2]

goroutine 1 [running]:
server.init()              //     vv-------------RIGHT HERE
    /home/.../debugComponent.go:-1218 +0x282
_/home/.../possessions.init()
    /home/.../possessions.go:29 +0x42
_/home/.../pageWrap.init()
    /home/.../pageWrap.go:112 +0x47

main.init()
    /home/.../main.go:0 +0x3c

goroutine 2 [syscall]:

goroutine 3 [runnable]:

The associated debugComponent.go file is pretty non-essential right now, so I removed it to see what would happen, and the file name just gets replaced with a different one, and a different negative number.

I've had to find plenty of bugs while developing this app, but this one has got me stumped.

If it helps, there's the main.go and then several packages in play. The three files listed above are all different packages, and this seems to be happening during the imports.

I hope you've read this far, because here's the strangest part. If I add this declaration to main.go, the error goes away!

var test = func() int { return 1 }() // Everything is fine now!

Very confusing! It doesn't fix it if I do var test = "foobar". It has to be the invoked func.

Any insight is appreciated, but mostly I'm curious about the -1218 in the trace.

Update

I'm trying to get this down to a small example that reproduces the issue. After working on it I reverted back to my original code, and restarted the machine.

The first time I tried to build and run, two new entries were added to the top of the stack trace. But only the first time.

goroutine 1 [syscall]:
syscall.Syscall()
	/usr/local/go/src/pkg/syscall/asm_linux_386.s:14 +0x5
syscall.Mkdir(0x83a2f18, 0x2, 0x2, 0x806255e, 0x83a2f1c, ...)
	/usr/local/go/src/pkg/syscall/zerrors_linux_386.go:2225 +0x80
server.init()

So this would be in line with my main question about interpreting stack trace. The -1218 is still there, but now there are these.

The asm_linux_386.s has this at line 14:

MOVL    4(SP), AX       // syscall entry

I found the zerrors_linux_386.go too, but there's no line 2225. The file stops long before that line.

It's already reported and accepted as Issue 5243.

> Program execution
>
> A package with no imports is initialized by assigning initial values
> to all its package-level variables and then calling any package-level
> function with the name and signature of
>
> func init()
>
> defined in its source. A package-scope or file-scope identifier with
> name init may only be declared to be a function with this signature.
> Multiple such functions may be defined, even within a single source
> file; they execute in unspecified order.
>
> Within a package, package-level variables are initialized, and
> constant values are determined, according to order of reference: if
> the initializer of A depends on B, A will be set after B. Dependency
> analysis does not depend on the actual values of the items being
> initialized, only on their appearance in the source. A depends on B if
> the value of A contains a mention of B, contains a value whose
> initializer mentions B, or mentions a function that mentions B,
> recursively. It is an error if such dependencies form a cycle. If two
> items are not interdependent, they will be initialized in the order
> they appear in the source, possibly in multiple files, as presented to
> the compiler. Since the dependency analysis is done per package, it
> can produce unspecified results if A's initializer calls a function
> defined in another package that refers to B.
>
> An init function cannot be referred to from anywhere in a program. In
> particular, init cannot be called explicitly, nor can a pointer to
> init be assigned to a function variable.
>
> If a package has imports, the imported packages are initialized before
> initializing the package itself. If multiple packages import a package
> P, P will be initialized only once.
>
> The importing of packages, by construction, guarantees that there can
> be no cyclic dependencies in initialization.
>
> A complete program is created by linking a single, unimported package
> called the main package with all the packages it imports,
> transitively. The main package must have package name main and declare
> a function main that takes no arguments and returns no value.
>
> func main() { … }
>
> Program execution begins by initializing the main package and then
> invoking the function main. When the function main returns, the
> program exits. It does not wait for other (non-main) goroutines to
> complete.
>
> Package initialization—variable initialization and the invocation of
> init functions—happens in a single goroutine, sequentially, one
> package at a time. An init function may launch other goroutines, which
> can run concurrently with the initialization code. However,
> initialization always sequences the init functions: it will not start
> the next init until the previous one has returned.

As your program begins execution, it initializes package variables and executes init functions. Adding package variables is going to change the initialization. It looks like the initialization failed in debugComponent.go on something related to server.init(). The negative line number is probably a bug.

Without the source code, it's hard to say more.