Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

invalid memory address or nil pointer dereference #529

Closed
zwzy29 opened this issue Aug 31, 2021 · 9 comments
Closed

invalid memory address or nil pointer dereference #529

zwzy29 opened this issue Aug 31, 2021 · 9 comments

Comments

@zwzy29
Copy link

zwzy29 commented Aug 31, 2021

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x50c278]

goroutine 1052658 [running]:
io.ReadAtLeast(0x0, 0x0, 0xc00060b5b0, 0x1, 0x1, 0x1, 0xc00010f3e0, 0xc000546f78, 0x175c601)
	/usr/local/go/src/io/io.go:328 +0x58
io.ReadFull(...)
	/usr/local/go/src/io/io.go:347
meihuan.com/badger/vendor/github.com/eclipse/paho.mqtt.golang/packets.ReadPacket(0x0, 0x0, 0xc000546f00, 0x1000000010000, 0x4ac416, 0x10ec9a8)
	/home/build/go/src/meihuan.com/badger/vendor/github.com/eclipse/paho.mqtt.golang/packets/packets.go:115 +0xa5
meihuan.com/badger/vendor/github.com/eclipse/paho%2emqtt%2egolang.startIncoming.func1(0x0, 0x0, 0xc0002f40d0, 0xc0002f40c0, 0xc00010f860)
	/home/build/go/src/meihuan.com/badger/vendor/github.com/eclipse/paho.mqtt.golang/net.go:119 +0xfd
created by meihuan.com/badger/vendor/github.com/eclipse/paho%2emqtt%2egolang.startIncoming
	/home/build/go/src/meihuan.com/badger/vendor/github.com/eclipse/paho.mqtt.golang/net.go:117 +0x131

my env:
go version:1.16.2
github.com/eclipse/paho.mqtt.golang v1.3.5

@MattBrittan
Copy link
Contributor

Are you sure you are using version 1.3.5? (I note that the library is vendored in your project so the version in use may not match your go.mod). The line numbers in the dump don't make sense with 1.3.5.

For example packets/packets.go:115 is part of the initialisation of a static variable. I could understand this error if you are using v1.1.1.

If you are using the latest version please provide more information (when this issue occurs, logging etc).

@zwzy29
Copy link
Author

zwzy29 commented Sep 1, 2021 via email

@MattBrittan
Copy link
Contributor

Apologies - I was looking at master and changes to the copyright notices have pushed everything around (thought I checked the right tag this morning but was mistaken). So looking at the info in the crashlog:

io.go:328 nn, err = r.Read(buf[n:])
io.go:347 return ReadAtLeast(r, buf, len(buf))
packets/packets.go:115 - _, err := io.ReadFull(r, b)
net.go:119 - if cp, err = packets.ReadPacket(conn); err != nil {

If appears that io.ReadFull is being called with a nil argument however the stack trace does not provide any info on potential causes. My assumption would be that this occurs on the initial connection meaning attemptConnection is returning a nil connection but no error; looking at that function I cannot see how that can happen.

Unfortunately without more information I'd be guessing at the cause and unlikely to find it. Please see the Reporting Bugs section of the readme for suggestions on the kinds of information that would help (at an absolute minimum I need a description of what is happening and to know what options you are using when setting up the client; however debug logs would make the process a lot easier).

@MattBrittan MattBrittan added the Details Required Further information (logs etc) is required before this issue can be investigated label Sep 1, 2021
@zwzy29
Copy link
Author

zwzy29 commented Sep 1, 2021 via email

@MattBrittan
Copy link
Contributor

MattBrittan commented Sep 1, 2021

OK - that explains it.

By default this client automatically reconnects if the connection is lost (see the documentation). This means that you may well be calling Connect when another connection attempt is in progress; this is not something we expect a user to do so there are limited checks for this (the checks are not fully thread safe and may allow two attempts to proceed at the same time under some circumstances). Having two connections running at the same time could result in an issue like this (there will be a range of potential race conditions).

I'd suggest that you use the built in reconnection functionality (quite a bit of thought has gone into making this resilient) rather than doing this yourself. If you want to do it yourself turn the built in functionality off with SetAutoReconnect(false) and call Disconnect before attempting to reconnect (to ensure the library has fully shutdown the initial connection).

@zwzy29
Copy link
Author

zwzy29 commented Sep 1, 2021 via email

@ahsandev2019
Copy link

any docker update for this issues?

@MattBrittan
Copy link
Contributor

@ahsandev2019 - sorry I'm not sure what you mean by your comment.

This particular issue is due to the library being used in an unexpected manner (using the automatic reconnect while also calling connect when the connection drops). While it would be possible to remove the potential race condition in Connect I don't think its a high priority as I would not expect it to be an issue other than when using the library incorrectly (as was the case here). This has nothing to do with docker so I'm a bit confused - if you have a problem perhaps raise a new issue.

@MattBrittan MattBrittan removed the Details Required Further information (logs etc) is required before this issue can be investigated label Jan 19, 2022
@MattBrittan
Copy link
Contributor

I'm going to close this because I believe it was addressed in PR #607 (the connection status is now actively monitored).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants