panic: runtime error: invalid memory address or nil pointer dereference #831
Comments
|
in the crash log you can see crypto libraries for amd64, this is however an armhf-latest tag (image: adguard/adguardhome:armhf-latest) |
|
I'm seeing the same crash happen with the AdGuard Home Hass.io add-on |
|
Guys, is this the full stack trace? I don't see our code in the stack trace, it's hard to figure where it comes from. |
|
Same here, unfortunately, I do not have a full stack trace: panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x50 pc=0x606775]
goroutine 425001 [running]:
crypto/tls.(*Conn).write(0xc00027d500, 0xc000f00000, 0x11d, 0x120, 0xc006478600, 0x118, 0x180)
/home/travis/.gimme/versions/go1.12.5.linux.amd64/src/crypto/tls/conn.go:896 +0x135
crypto/tls.(*Conn).writeRecordLocked(0xc00027d500, 0xbb5f16, 0xc006478600, 0x118, 0x180, 0x0, 0x0, 0x0)
/home/travis/.gimme/versions/go1.12.5.linux.amd64/src/crypto/tls/conn.go:945 +0x2a1
crypto/tls.(*Conn).writeRecord(0xc00027d500, 0xc006478616, 0xc006478600, 0x118, 0x180, 0x0, 0x0, 0x0)
/home/travis/.gimme/versions/go1.12.5.linux.amd64/src/crypto/tls/conn.go:967 +0xaf
crypto/tls.(*Conn).clientHandshake(0xc00027d500, 0x0, 0x0)
/home/travis/.gimme/versions/go1.12.5.linux.amd64/src/crypto/tls/handshake_client.go:167 +0x17c
crypto/tls.(*Conn).Handshake(0xc00027d500, 0x0, 0x0)
/home/travis/.gimme/versions/go1.12.5.linux.amd64/src/crypto/tls/conn.go:1343 +0xef
net/http.(*persistConn).addTLS.func2(0x0, 0xc00027d500, 0xc000dc00f0, 0xc0060a6360)
/home/travis/.gimme/versions/go1.12.5.linux.amd64/src/net/http/transport.go:1190 +0x42
created by net/http.(*persistConn).addTLS
/home/travis/.gimme/versions/go1.12.5.linux.amd64/src/net/http/transport.go:1186 +0x1ab |
|
This is all I have before the signal: $ docker-compose up adguard |
|
Is there any issue if you change the upstream to As I understand, this happens only with:
|
|
@ameshkov I run amd64, so 1 & 3 are not valid conclusions. |
|
Got it, so it's just |
|
Found the issue. It is related to systemd-resolved. On Hypriot the systemd-resolved is bound to 127.0.0.1:53 and this crashes Adguard with macvlan support (even so Adguard is starting on an 192.168.1.x ip). Without macvlan it just says the port is in use, but since macvlan is bound to another IP this should not crash. |
|
So disabling |
|
this is what I did to solve it: to answer your question: yes |
|
Well, the only thing I don't understand now is what crypto/tls has to do with this all? 🤔 |
|
yeah, that is what put me on the wrong track... |
|
Even starting systemd-resolved when Adguard is running (with macvlan) doesn't crash it anymore, maybe the start of Adguard tries to open the wrong ip/port combo ? |
|
Disregard that statement, it just went down with signal 2 |
|
Could you please run it with verbose logging enabled? |
|
I don't want to spoil the party, but I don't run systemd-resolved in my system. It has been hard disabled and DNS management by the NetworkManager has been disabled as well, still, I run into this. Edit: Nevermind, @vtacquet told already to disregard. |
|
Guys, what about using a different upstream? #831 (comment) Does it change anything? |
|
@ameshkov I can test it... nevertheless, I do not have a reproduction trigger, as in, it occurs rarely at my end. (ran for a week without this happening). |
|
It is not solved at all, it just takes some time to crash: adguard | 2019/06/17 12:42:23 [info] AdGuard Home, version v0.96-hotfix, channel release |
|
setting another upstream (8.8.8.8) with macvlan is no solution, it crashes every minute |
|
@vtacquet hmm, so this is not DOH. Another question: do you have "browsing security" or "parental control" enabled? |
|
None of those enabled for the moment. It's a standard install. |
|
I'd like to figure out what this goroutine was doing before the panic occurred. Could you please record the verbose log (set verbose: true in the config). Meanwhile, we're trying to reproduce this on our side, but no luck so far. |
|
Starting adguard ... done |
|
I can't get it to fail with running a docker command, only when starting it from docker-compose. Must have something to do with macvlan on docker-compose (there is a bug where the gateway is not added to a macvlan network - hence the problem connecting to 1.1.1.1 and cloudflare) |
|
Well, that was easier than I thought, we should've started with the log :) The new docker image will be soon available in the |
Steps to reproduce
Expected behavior
it should not crash
(without macvlan it does not crash)
Actual behavior
adguard | panic: runtime error: invalid memory address or nil pointer dereference
adguard | [signal SIGSEGV: segmentation violation code=0x1 addr=0x2c pc=0x1d89a8]
adguard |
adguard | goroutine 41 [running]:
adguard | crypto/tls.(*Conn).write(0x2fb0000, 0x2ca83c0, 0x125, 0x140, 0x2fd6000, 0x120, 0x180)
adguard | /home/travis/.gimme/versions/go1.12.5.linux.amd64/src/crypto/tls/conn.go:896 +0xf4
adguard | crypto/tls.(*Conn).writeRecordLocked(0x2fb0000, 0x6c9416, 0x2fd6000, 0x120, 0x180, 0x0, 0x0, 0x0)
adguard | /home/travis/.gimme/versions/go1.12.5.linux.amd64/src/crypto/tls/conn.go:945 +0x1fc
adguard | crypto/tls.(*Conn).writeRecord(0x2fb0000, 0x2fd6016, 0x2fd6000, 0x120, 0x180, 0x0, 0x0, 0x0)
adguard | /home/travis/.gimme/versions/go1.12.5.linux.amd64/src/crypto/tls/conn.go:967 +0x90
adguard | crypto/tls.(*Conn).clientHandshake(0x2fb0000, 0x0, 0x0)
adguard | /home/travis/.gimme/versions/go1.12.5.linux.amd64/src/crypto/tls/handshake_client.go:167 +0x114
adguard | crypto/tls.(*Conn).Handshake(0x2fb0000, 0x0, 0x0)
adguard | /home/travis/.gimme/versions/go1.12.5.linux.amd64/src/crypto/tls/conn.go:1343 +0xe8
adguard | net/http.(*persistConn).addTLS.func2(0x0, 0x2fb0000, 0x0, 0x2cb8300)
adguard | /home/travis/.gimme/versions/go1.12.5.linux.amd64/src/net/http/transport.go:1190 +0x34
adguard | created by net/http.(*persistConn).addTLS
adguard | /home/travis/.gimme/versions/go1.12.5.linux.amd64/src/net/http/transport.go:1186 +0x174
Screenshot:
 Your environment
The text was updated successfully, but these errors were encountered: