Same pointer different values, in multi file main package

My project is a login-register web server that consists of multiple files and uses another package in which the Manager struct is defined.

Overview of my files:

my-package/
       main.go
       handlers.go
       ...

I have a variable: var M *Manager declared in main.go before definition of main() and it is assigned inside main():

var M *Manager

func main() {
  ...
  M = InitManager(...)
  ...
}

handleLogin(...) and handleRegister(...) are functions defined in handlers.go that use the M variable:

func handleRegister(...){
  ...
  fmt.Println("M:", M)
  M.Log1("logging informations...")
  ...
}


func handleLogin(...) {
  ...
  fmt.Println("M:", M)
  M.GetAccount(login)
  ...
}

When I go to /loginor /register and the appropriate handle function is triggered it displays: M: <nil>

To find out something more I modified main() as shown below:

var M *Manager

func main() {
  ...
  go func() {  // for debugging
    for {
      fmt.Println("main() goloop1: M:", M)
      time.Sleep(time.Second / 2)
    }
  }()

  M = InitManager(...)

  go func() {  // for debugging
    for {
      fmt.Println("main() goloop2: M:", M)
      time.Sleep(time.Second / 2)
    }
  }()
  ...
}

and the output:

main() goloop2: M: &{...data as expected...}
main() goloop1: M: <nil>
main() goloop2: M: &{...data as expected...}
main() goloop1: M: <nil>
...

My question are:

1. How do pointers work then if one pointer gives out two values?
2. How to fix my issue and properly plan code (if that was the cause) to avoid this in future?

Per the Go Memory Model, the provided code writes and reads M without proper synchronization, which is a data race and leads to undefined behavior (see icza's comment).

The compiler "assumes" that the code is properly synchronized (this is the responsibility of the developer) and so it is "allowed" to assume that M is never modified inside the infinite loops, so it may use a copy in a given register or stack memory location over and over, leading to the surprising output.

You may use a sync.Mutex to protect every access to the global *Manager variable M, as in this modified code.

Also beware of variable shadowing! It is possible to write M := f() instead of M = f(), resulting in an unrelated local variable, not affecting the global variable.

My solution:

I have added init.go:

my-package/
       main.go
       handlers.go
       ...
       init.go

I moved global variables like M and CONFIG_MAP into the init.go file:

package main

import ...

var CONFIG_MAP = LoadConfig()
var M *asrv.Manager = InitManager()

func LoadConfig() map[string]string {
    // return map from 'conf.json' file
}

func InitManager() *asrv.Manager {
    // return Manager configured with CONFIG_MAP
    // other functions also use CONFIG_MAP that is the reason why it is global
}

func init() {
	LoadTemplatesFiles() // load templates and assign value
                         // to a variable declared in templates.go
}

This way handler functions (handleLoginGet etc.) in handlers.go could properly read M.

This fix just made my program work and I still don't know what is the proper way of handling this type of situation, that is why I added more info under EDIT in my question.