On Sunday, 21 March 2021 at 11:20:40 UTC Van Fury wrote:
> After this , the PATCH message is send OK but when server B stop running,
> server A break, complain g about the status check in the PATCH for loop
>
> status204ERRO[0350] Patch "
> http://127.0.0.1:9090/nnrf-nfm/v1/nf-instances/6ba7b810-9dad-11d1-80b4-00c04fd430c9":
>
> dial tcp 127.0.0.1:9090: connect: connection refused
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xe6aa92]
>
> goroutine 47 [running]:
> PutAndPatch()
> register.go:147 +0x1d2
> exit status 2
>
>
Can you show the code at line 147 of register.go, with two or three lines
of context either side?
My guess is that your problem is here:
interval, cl, resp = SendNFInstanceRegistration()
* status := resp.StatusCode*
or here:
htbt, contentLoc, resp, err :=
HandleNFInstanceRegistration(locProfilebytes, locVarUrl)
if err != nil {
logrus.Error("Server A could not register profile")
}
* status := resp.StatusCode*
In either case, what happens if resp is nil? You have checked for the case
of err != nil, but you only make a log message - and then continue blithely
on as if everything was successful. But in the case of error, resp is
likely to be nil, and you can't dereference a nil pointer. That's what
causes the panic.
Also: somebody has to be responsible for closing the response. You're not
explicitly returning an error from SendNFInstanceRegistration() to
HandleNFInstanceRegistration(), so the only way you can indicate that the
body is invalid is to return nil as the response pointer.
interval, cl, resp = SendNFInstanceRegistration()
* if resp == nil {*
... log if you like
* return ...*
* }*
* defer resp.Body.Close()*
status := resp.StatusCode
.... continue to parse the response
Personally I think it would be cleaner to return an explicit "err", as it's
consistent with the normal conventions.
You still aren't checking the error response from json.Unmarshal(bodybytes,
&nfprofile). If the JSON parsing fails then you'll get a zero response for
the timer interval, and a ticker with a zero interval will cause a panic.
I think I'll leave it with you now. In short: check errors everywhere;
take the correct action on error - which might just be returning the error
to the caller, but don't just ignore it and carry on as if everything was
OK. And make sure things are closed that need to be closed.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/3edf6058-6e38-4cf4-841c-c4be7c9dc949n%40googlegroups.com.
