I've tried making out from the source code what's happening, but I had to give up. The

It seems to be dieing on requests like this: <div class="snippet-clipboard-content

dnscrypt-wrapper dies on "resolver read callback",about cofyc/dnscrypt-wrapper

Comments (26)

cofyc commented on June 1, 2024

Hi,

I'm looking at the code for this problem and it looks like it has a bug in TCP handling.

from dnscrypt-wrapper.

simonclausen commented on June 1, 2024

Ok.

Again, let me know if there is anything I can do to help.

from dnscrypt-wrapper.

cofyc commented on June 1, 2024

Could you provide the last few lines of the log when it crashed and its command line options?

from dnscrypt-wrapper.

cofyc commented on June 1, 2024

I pushed a commit. Can you test against master and let me know if this resolves this issue please?

from dnscrypt-wrapper.

simonclausen commented on June 1, 2024

I run it with "-d -r -a --crypt-secretkey-file= --crypt-publickey-file= --provider-cert-file= --provider-name= --logfile= -VVVV" flags. The resolver is located on the same machine as dnscrypt-wrapper, listening on 127.0.0.1.

I've compiled and started running with the current master - I'll get back to you on how it goes.

from dnscrypt-wrapper.

simonclausen commented on June 1, 2024

Ok, it still dies in the same way. This is the log of two (re)starts. Running with the same flags as mentioned before.

[13721] 28 Sep 12:46:59.155 [info] Crypt public key fingerprint: 6231:4AFE:4AA3:7E6F:9B8C:DAA6:6F6E:E8A5:F84B:10A8:6DB1:C5CB:D264:77CA:7F03:0D5C
[13722] 28 Sep 12:46:59.434 [debug] client to proxy cb
[13722] 28 Sep 12:46:59.440 [debug] resolver to proxy cb
[13722] 28 Sep 12:46:59.892 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:46:59.958 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:46:59.997 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.015 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.093 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.194 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.210 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.210 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.211 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.227 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.289 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.344 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.405 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.499 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.519 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.596 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.708 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.729 [debug] Resolver read callback.
[13722] 28 Sep 12:47:00.731 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.731 [debug] Accepted a tcp connection.
[13722] 28 Sep 12:47:00.754 [debug] Resolver read callback.
[13726] 28 Sep 12:47:11.010 [info] Crypt public key fingerprint: 6231:4AFE:4AA3:7E6F:9B8C:DAA6:6F6E:E8A5:F84B:10A8:6DB1:C5CB:D264:77CA:7F03:0D5C
[13727] 28 Sep 12:47:11.147 [debug] client to proxy cb
[13727] 28 Sep 12:47:11.151 [debug] resolver to proxy cb
[13727] 28 Sep 12:47:11.499 [debug] client to proxy cb
[13727] 28 Sep 12:47:11.573 [debug] resolver to proxy cb
[13727] 28 Sep 12:47:11.727 [debug] client to proxy cb
[13727] 28 Sep 12:47:11.744 [debug] resolver to proxy cb
[13727] 28 Sep 12:47:11.843 [debug] client to proxy cb
[13727] 28 Sep 12:47:11.846 [debug] resolver to proxy cb
[13727] 28 Sep 12:47:11.874 [debug] Accepted a tcp connection.
[13727] 28 Sep 12:47:11.955 [debug] client to proxy cb
[13727] 28 Sep 12:47:12.078 [debug] Accepted a tcp connection.
[13727] 28 Sep 12:47:12.170 [debug] resolver to proxy cb
[13727] 28 Sep 12:47:12.233 [debug] client to proxy cb
[13727] 28 Sep 12:47:12.254 [debug] resolver to proxy cb
[13727] 28 Sep 12:47:12.347 [debug] client to proxy cb
[13727] 28 Sep 12:47:12.352 [debug] resolver to proxy cb
[13727] 28 Sep 12:47:12.462 [debug] client to proxy cb
[13727] 28 Sep 12:47:12.465 [debug] resolver to proxy cb
[13727] 28 Sep 12:47:12.692 [debug] client to proxy cb
[13727] 28 Sep 12:47:12.698 [debug] resolver to proxy cb
[13727] 28 Sep 12:47:13.159 [debug] client to proxy cb
[13727] 28 Sep 12:47:13.163 [debug] client to proxy cb
[13727] 28 Sep 12:47:13.173 [debug] resolver to proxy cb
[13727] 28 Sep 12:47:13.178 [debug] resolver to proxy cb
[13727] 28 Sep 12:47:13.464 [debug] client to proxy cb
[13727] 28 Sep 12:47:13.467 [debug] resolver to proxy cb
[13727] 28 Sep 12:47:13.475 [debug] Resolver read callback.

from dnscrypt-wrapper.

simonclausen commented on June 1, 2024

It seems to be dieing on requests like this:

28-Sep-2013 13:01:18.528 client 127.0.0.1#51739: query: (removed) IN A +ETDC (127.0.0.1)

So one of the "ETDC" flags are causing trouble:
E: EDNS was in use
T: if TCP was used
D: if DO (DNSSEC Ok) was set
C: if CD (Checking Disabled) was set

EDNS does not seem to be the problem. A bunch of PTR queries like this are passed fine:

28-Sep-2013 13:10:33.063 client 127.0.0.1#52470: query: (removed) IN PTR +E (127.0.0.1)

A couple of these are also passed without problem:

28-Sep-2013 13:11:38.310 client 127.0.0.1#41614: query: (removed) IN A +EDC (127.0.0.1)

By processes of elimination - something must be going wrong in the TCP requests (as you've mentioned).

from dnscrypt-wrapper.

cofyc commented on June 1, 2024

I added a special assert macro to show more info when assertion fails. Please test again with latest master and show me the logs when it dies.

And could you provide more info about your clients? Normal system resolver or dnscrypt-proxy or mixed of them?

I tested against dnscrypt-wrapper with dig, but I couldn't find a case to cause dnscrypt-wrapper to die. If you can give me a example (dig command or any other dns client query example), it would be very helpful.

from dnscrypt-wrapper.

simonclausen commented on June 1, 2024

All the traffic going to BIND is coming from dnscrypt-wrapper on localhost.

I'll load up the new revision and report back in a bit.

from dnscrypt-wrapper.

simonclausen commented on June 1, 2024

I'm not seeing any more information is logged when it crashes. But have a look at this - I can induce the death with this:

dig @127.0.0.1 yahoo.com +tcp +dnssec +edns=0 +cdflag

Which results in this:

28-Sep-2013 16:48:59.051 client 127.0.0.1#45035: query: yahoo.com IN A +ETDC (127.0.0.1)

... and a dnscrypt-wrapper crash.

Upon further investigation it looks like it's the combination of +tcp and +cdflag that does the job:

dig @127.0.0.1 yahoo.com +tcp +cdflag

28-Sep-2013 16:52:14.803 client 127.0.0.1#50787: query: yahoo.com IN A +TC (127.0.0.1)

(This kills dnscrypt-wrapper)

Not asking for DNSSEC and then saying you'd like to receive the DNSSEC, even though it's not checked, seems inconsistent. This may be the cause of the crash?

Edit: strike that last remark. Even with a request for DNSSEC it will kill the wrapper.

from dnscrypt-wrapper.

cofyc commented on June 1, 2024

dig @127.0.0.1 yahoo.com +tcp +dnssec +edns=0 +cdflag

It's ok on my machine...

My dnscrypt-wrapper resolver is 8.8.8.8. Can you use 8.8.8.8 as dnscrypt-wrapper resolver address and test again?

Sorry, it's weird, it may take some time to fix.

from dnscrypt-wrapper.

cofyc commented on June 1, 2024

I created issue4 branch https://github.com/Cofyc/dnscrypt-wrapper/tree/issue4, it contains some debug code to print query & reply binary string.

Can you induce the death with command above against this branch and then show me the logs?

from dnscrypt-wrapper.

simonclausen commented on June 1, 2024

Ok, I've tried out Google's servers. While dnscrypt-wrapper also dies using them, it seems to happen less frequently and not at all with the example yahoo.com dig from before - at least not in the few hundred lookups I made with it.

I've also tried using other public BIND servers, which behave like running a local BIND.

It will happen with Google's servers as well, but combining the wrapper with BIND seems more volatile.

I'll get the debug branch set up and get back to you.

from dnscrypt-wrapper.

simonclausen commented on June 1, 2024

This may be a dumb question - but shouldn't it output to log? Using "--logfile=" - I'm not seeing any additional output:

[26351] 28 Sep 18:47:29.736 [debug] resolver to proxy cb
[26351] 28 Sep 18:47:30.337 [debug] client to proxy cb
[26351] 28 Sep 18:47:30.340 [debug] resolver to proxy cb
[26351] 28 Sep 18:47:30.734 [debug] client to proxy cb
[26351] 28 Sep 18:47:30.737 [debug] resolver to proxy cb
[26351] 28 Sep 18:47:30.979 [debug] Accepted a tcp connection.
[26351] 28 Sep 18:47:30.983 [debug] Resolver read callback.

I also checked that I'm actually compiling the issue4 branch version :)

from dnscrypt-wrapper.

cofyc commented on June 1, 2024

Sorry I didn't mention it, I made it output to stdout.

You can run it without '-d' and '--logfile' in a separate terminal, then test against it.

from dnscrypt-wrapper.

cofyc commented on June 1, 2024

And how did you perform hundreds of lookups against it? I am trying to find a way to cause it to die.

from dnscrypt-wrapper.

simonclausen commented on June 1, 2024

Assuming you are using bash, this will do the job:

for ((a=1; a <= 200; a++)); do dig @127.0.0.1 yahoo.com +tcp +dnssec +edns=0 +cdflag; done

I should have thought to check stdout, sorry.

[22029] 29 Sep 07:26:22.864 [info] Crypt public key fingerprint: 6231:4AFE:4AA3:7E6F:9B8C:DAA6:6F6E:E8A5:F84B:10A8:6DB1:C5CB:D264:77CA:7F03:0D5C
[22029] 29 Sep 07:26:24.175 [debug] client to proxy cb
[22029] 29 Sep 07:26:24.185 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:25.537 [debug] client to proxy cb
[22029] 29 Sep 07:26:25.543 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:26.376 [debug] client to proxy cb
[22029] 29 Sep 07:26:26.380 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:26.490 [debug] client to proxy cb
[22029] 29 Sep 07:26:26.494 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:27.491 [debug] client to proxy cb
[22029] 29 Sep 07:26:27.494 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:28.493 [debug] client to proxy cb
[22029] 29 Sep 07:26:28.498 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:29.494 [debug] client to proxy cb
[22029] 29 Sep 07:26:29.497 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:30.496 [debug] client to proxy cb
[22029] 29 Sep 07:26:30.500 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:31.497 [debug] client to proxy cb
[22029] 29 Sep 07:26:31.502 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:32.498 [debug] client to proxy cb
[22029] 29 Sep 07:26:32.503 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:33.501 [debug] client to proxy cb
[22029] 29 Sep 07:26:33.504 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:34.502 [debug] client to proxy cb
[22029] 29 Sep 07:26:34.504 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:34.969 [debug] Accepted a tcp connection.
0000: da c0 01 10 00 01 00 00 00 00 00 01 05 79 61 68
0010: 6f 6f 03 63 6f 6d 00 00 01 00 01 00 00 29 10 00
0020: 00 00 80 00 00 00
[22029] 29 Sep 07:26:34.974 [debug] Resolver read callback.
dns_reply_len: 256
available_size: 256
0000: da c0 81 90 00 01 00 03 00 05 00 06 05 79 61 68
0010: 6f 6f 03 63 6f 6d 00 00 01 00 01 c0 0c 00 01 00
0020: 01 00 00 06 ed 00 04 62 8a fd 6d c0 0c 00 01 00
0030: 01 00 00 06 ed 00 04 62 8b b7 18 c0 0c 00 01 00
0040: 01 00 00 06 ed 00 04 ce be 24 2d c0 0c 00 02 00
0050: 01 00 00 e9 d8 00 06 03 6e 73 33 c0 0c c0 0c 00
0060: 02 00 01 00 00 e9 d8 00 06 03 6e 73 35 c0 0c c0
0070: 0c 00 02 00 01 00 00 e9 d8 00 06 03 6e 73 34 c0
0080: 0c c0 0c 00 02 00 01 00 00 e9 d8 00 06 03 6e 73
0090: 31 c0 0c c0 0c 00 02 00 01 00 00 e9 d8 00 06 03
00a0: 6e 73 32 c0 0c c0 8d 00 01 00 01 00 00 e9 d8 00
00b0: 04 44 b4 83 10 c0 9f 00 01 00 01 00 00 e9 d8 00
00c0: 04 44 8e ff 10 c0 57 00 01 00 01 00 00 e9 d8 00
00d0: 04 cb 54 dd 35 c0 7b 00 01 00 01 00 00 e9 d8 00
00e0: 04 62 8a 0b 9d c0 69 00 01 00 01 00 00 e9 d8 00
00f0: 04 77 a0 f7 7c 00 00 29 10 00 00 00 80 00 00 00

[22029] 29 Sep 07:26:35.503 [debug] client to proxy cb
[22029] 29 Sep 07:26:35.508 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:36.504 [debug] client to proxy cb
[22029] 29 Sep 07:26:36.507 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:37.280 [debug] client to proxy cb
[22029] 29 Sep 07:26:37.285 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:37.506 [debug] client to proxy cb
[22029] 29 Sep 07:26:37.509 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:38.440 [debug] client to proxy cb
[22029] 29 Sep 07:26:38.442 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:38.507 [debug] client to proxy cb
[22029] 29 Sep 07:26:38.510 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:39.509 [debug] client to proxy cb
[22029] 29 Sep 07:26:39.514 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:40.511 [debug] client to proxy cb
[22029] 29 Sep 07:26:40.514 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:41.512 [debug] client to proxy cb
[22029] 29 Sep 07:26:41.515 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:42.513 [debug] client to proxy cb
[22029] 29 Sep 07:26:42.517 [debug] resolver to proxy cb
[22029] 29 Sep 07:26:42.754 [debug] Accepted a tcp connection.
0000: 8b 6d 01 10 00 01 00 00 00 00 00 01 05 79 61 68
0010: 6f 6f 03 63 6f 6d 00 00 01 00 01 00 00 29 10 00
0020: 00 00 80 00 00 00
[22029] 29 Sep 07:26:42.757 [debug] Resolver read callback.
dns_reply_len: 256
available_size: 256
0000: 8b 6d 81 90 00 01 00 03 00 05 00 06 05 79 61 68
0010: 6f 6f 03 63 6f 6d 00 00 01 00 01 c0 0c 00 01 00
0020: 01 00 00 06 e5 00 04 62 8b b7 18 c0 0c 00 01 00
0030: 01 00 00 06 e5 00 04 ce be 24 2d c0 0c 00 01 00
0040: 01 00 00 06 e5 00 04 62 8a fd 6d c0 0c 00 02 00
0050: 01 00 00 e9 d0 00 06 03 6e 73 31 c0 0c c0 0c 00
0060: 02 00 01 00 00 e9 d0 00 06 03 6e 73 32 c0 0c c0
0070: 0c 00 02 00 01 00 00 e9 d0 00 06 03 6e 73 34 c0
0080: 0c c0 0c 00 02 00 01 00 00 e9 d0 00 06 03 6e 73
0090: 33 c0 0c c0 0c 00 02 00 01 00 00 e9 d0 00 06 03
00a0: 6e 73 35 c0 0c c0 57 00 01 00 01 00 00 e9 d0 00
00b0: 04 44 b4 83 10 c0 69 00 01 00 01 00 00 e9 d0 00
00c0: 04 44 8e ff 10 c0 8d 00 01 00 01 00 00 e9 d0 00
00d0: 04 cb 54 dd 35 c0 7b 00 01 00 01 00 00 e9 d0 00
00e0: 04 62 8a 0b 9d c0 9f 00 01 00 01 00 00 e9 d0 00
00f0: 04 77 a0 f7 7c 00 00 29 10 00 00 00 80 00 00 00

*** glibc detected *** <unknown>: free(): invalid next size (normal): 0x09e98a60 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x70a8a)[0xb75eca8a]
/lib/i386-linux-gnu/libc.so.6(+0x722e8)[0xb75ee2e8]
/lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0xb75f13ed]
[0x805305d]
======= Memory map: ========
08048000-0806f000 r-xp 00000000 08:05 23753140                           /usr/local/bin/dnscrypt-wrapper
0806f000-08070000 rw-p 00026000 08:05 23753140                           /usr/local/bin/dnscrypt-wrapper
09e98000-09eb9000 rw-p 00000000 00:00 0                                  [heap]
b7400000-b7421000 rw-p 00000000 00:00 0
b7421000-b7500000 ---p 00000000 00:00 0
b7540000-b755c000 r-xp 00000000 08:05 22958116                           /lib/i386-linux-gnu/libgcc_s.so.1
b755c000-b755d000 rw-p 0001b000 08:05 22958116                           /lib/i386-linux-gnu/libgcc_s.so.1
b7562000-b7563000 rw-p 00000000 00:00 0
b7563000-b7578000 r-xp 00000000 08:05 22958109                           /lib/i386-linux-gnu/libpthread-2.13.so
b7578000-b7579000 r--p 00014000 08:05 22958109                           /lib/i386-linux-gnu/libpthread-2.13.so
b7579000-b757a000 rw-p 00015000 08:05 22958109                           /lib/i386-linux-gnu/libpthread-2.13.so
b757a000-b757c000 rw-p 00000000 00:00 0
b757c000-b76c3000 r-xp 00000000 08:05 22958199                           /lib/i386-linux-gnu/libc-2.13.so
b76c3000-b76c4000 ---p 00147000 08:05 22958199                           /lib/i386-linux-gnu/libc-2.13.so
b76c4000-b76c6000 r--p 00147000 08:05 22958199                           /lib/i386-linux-gnu/libc-2.13.so
b76c6000-b76c7000 rw-p 00149000 08:05 22958199                           /lib/i386-linux-gnu/libc-2.13.so
b76c7000-b76ca000 rw-p 00000000 00:00 0
b76ca000-b76d1000 r-xp 00000000 08:05 22958264                           /lib/i386-linux-gnu/librt-2.13.so
b76d1000-b76d2000 r--p 00006000 08:05 22958264                           /lib/i386-linux-gnu/librt-2.13.so
b76d2000-b76d3000 rw-p 00007000 08:05 22958264                           /lib/i386-linux-gnu/librt-2.13.so
b76d3000-b76d4000 rw-p 00000000 00:00 0
b76d4000-b773e000 r-xp 00000000 08:05 23733916                           /usr/local/lib/libsodium.so.4.3.0
b773e000-b773f000 r--p 00069000 08:05 23733916                           /usr/local/lib/libsodium.so.4.3.0
b773f000-b7748000 rw-p 0006a000 08:05 23733916                           /usr/local/lib/libsodium.so.4.3.0
b7748000-b776c000 r-xp 00000000 08:05 22958232                           /lib/i386-linux-gnu/libm-2.13.so
b776c000-b776d000 r--p 00023000 08:05 22958232                           /lib/i386-linux-gnu/libm-2.13.so
b776d000-b776e000 rw-p 00024000 08:05 22958232                           /lib/i386-linux-gnu/libm-2.13.so
b7772000-b7775000 rw-p 00000000 00:00 0
b7775000-b7791000 r-xp 00000000 08:05 22958192                           /lib/i386-linux-gnu/ld-2.13.so
b7791000-b7792000 r--p 0001b000 08:05 22958192                           /lib/i386-linux-gnu/ld-2.13.so
b7792000-b7793000 rw-p 0001c000 08:05 22958192                           /lib/i386-linux-gnu/ld-2.13.so
b7793000-b7794000 r-xp 00000000 00:00 0                                  [vdso]
bf9fe000-bfa13000 rw-p 00000000 00:00 0                                  [stack]
Aborted

This is the output containing two dig yahoo.com +tcp +dnssec +edns=0 +cdflag. The first (07:26:34.969) goes through without problem, but it dies on the second (07:26:42.754).

from dnscrypt-wrapper.

cofyc commented on June 1, 2024

I tested on mac & ubuntu (32bit/64bit), and all is ok.

What's your os? 32bit or 64 bit? Please provide output of uname -a command.

And can you update your glibc library and recompile all from source and then test it again?

Haven't you tested them on another machine?

from dnscrypt-wrapper.

simonclausen commented on June 1, 2024

This is on Debian 7 32-bit. I've tested it on two machines, with different kernels:

Linux dnscrypt1 2.6.32-042stab079.6 #1 SMP Mon Aug 26 19:47:50 MSK 2013 i686     /Linux

Linux orion 3.2.0-4-686-pae #1 SMP Debian 3.2.41-2 i686 GNU/Linux

Both are using the precompiled Debian versions of glibc (2.13) and both are seeing the crash.

Debian 7 64-bit with glibc 2.13 and the following kernel is working just fine, as far as I can tell (did 1000 lookups without incident):

Linux orion 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux

I maybe be able to find the time to do my own compile of glibc from source later, to replace the prebuilt version included in Debian. But so far, it looks like we're getting closer to the issue.

from dnscrypt-wrapper.

cofyc commented on June 1, 2024

Thanks!

I will test it in 32 bit system. (I just tested with 32 bit dnscrypt-wrapper compiled in 64 bit system)

from dnscrypt-wrapper.

cofyc commented on June 1, 2024

Hi,

I installed a debian 7 32-bit system in VirtualBox, and tested in it without any problem.

uname -a:

Linux debian 3.2.0-4-686-pae #1 SMP Debian 3.2.41-2 i686 GNU/Linux

ldd --version:

ldd (Debian EGLIBC 2.13-38) 2.13

Sorry, can you use it in 64-bit system temporarily?

P.S. I removed dnscrypt-proxy submodule from source, and use system libevent library. (This is not related to this issue.)

from dnscrypt-wrapper.

simonclausen commented on June 1, 2024

That's strange - I can give you access to one of the Debian installations, if you'd like.

I've considered switching to 64bit anyway, so I'll just do that - no problem.

from dnscrypt-wrapper.

cofyc commented on June 1, 2024

This is my public key:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC5a5A1Nej0RmYY0iDnScaMHKib2xQRi8RHUgrD0Yu8o4Z7t3AkGZXYrxUyUqzby+vwCoPgZYGe5i2IJ5eJw998QKVmiugJw8oTcTK1lJklGbOZtDpMLCZaCeKwkuRu66CjUrxnUAdYS2iOGF/rONmDbmntuwvfxCZcI7qqc1LEg0cIMNFPsDr1HVOpoYR4wTw0CSpfmgBHDQEzOKfqJJCJsLv0jJcix+bjJ5e+IlDJdIih6C1HDd6qfE/0v23tNivpKVwNFxJPZcohF06QXYD7WGAZoN3iFmKmN53vQp59WeXFA5VXh31lPUZ7+y7JR0NefooQp7Wlcy4l7HczuY1T [email protected]

from dnscrypt-wrapper.

cofyc commented on June 1, 2024

Hi, I pushed a commit to master branch.

I did some tests, it works now. This issue is not related to 32 bit or 64 bit.

You can test again.

from dnscrypt-wrapper.

simonclausen commented on June 1, 2024

Ok. I've installed the new version.

Thank you very much for your help and effort!

Out of curiosity, what was the problem?

from dnscrypt-wrapper.

cofyc commented on June 1, 2024

Sorry for the late fix. Thanks for your patience!

The bug is invalid memory write.

I wrote curved dns result back into event buffer before. It's ok in some times when the underlying event buffer is big enough, but we cannot guarantee that.

from dnscrypt-wrapper.

dnscrypt-wrapper dies on "resolver read callback" about dnscrypt-wrapper HOT 26 CLOSED

Comments (26)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent