TLS connect error: "an EOF was observed that violates the protocol"
Hi, Here are 2 separate issues: 1) socks5 proxy on 127.0.0.1:8080 not working. This is a proxy over ssh, for example: ssh -N -D 8080 user@example.com in dillorc: http_proxy="http://localhost:8080/" console output when trying to connect to a site: Connecting to 127.0.0.1:8080 CONNECT through proxy failed. Full reply not received: (nothing) ** WARNING **: CCC: call on already finished chain. Flags=CCC_Ended This setup works fine under Firefox. I tried doing a tcpdump while attempting the connection, and there is no activity. So, while trying to research this, I ran into another issue: 2) Any time I go to a page on this site, Dillo crashes with the following: Nav_open_url: new url='https://dillo-dev.auriga.wearlab.narkive.com/WT0JYUZq/dillo-won-t-resolve-ur...' Dns_server [0]: dillo-dev.auriga.wearlab.narkive.com is 149.248.211.108 Connecting to 149.248.211.108:443 TLS connect error: "an EOF was observed that violates the protocol" Tls_close_by_key: Avoiding SSL shutdown for: https://dillo-dev.auriga.wearlab.narkive.com/WT0JYUZq/dillo-won-t-resolve-ur... fd 6 is done and failed dillo(13689) in malloc(): write to free mem 0x60383b59140[24..31]@32 Abort trap gdb output: Program received signal SIGABRT, Aborted. thrkill () at /tmp/-:2 2 /tmp/-: No such file or directory. in /tmp/- This is on OpenBSD-current amd64 with LibreSSL 3.9.0, running an unmodified fresh checkout of Dillo master. Also tested on OpenBSD 7.5 with the same result. I tested the site with: https://www.ssllabs.com/ssltest/analyze.html?d=dillo-dev.auriga.wearlab.nark... There seem to be some handshake failures during the simulation. This probably is not be the fault of Dillo, but maybe there is a more graceful to handle this, rather than crashing. Even a test with curl has issues: curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to dillo-dev.auriga.wearlab.narkive.com:443 Is this site just broken/misconfigured? Regards, Alex
Hi Alex, On Tue, Aug 27, 2024 at 11:55:04AM +0200, a1ex@dismail.de wrote:
Hi,
Here are 2 separate issues:
1) socks5 proxy on 127.0.0.1:8080 not working.
There is currently no support for socks5 proxies, only HTTP proxies are supported.
This is a proxy over ssh, for example: ssh -N -D 8080 user@example.com
in dillorc: http_proxy="http://localhost:8080/"
console output when trying to connect to a site: Connecting to 127.0.0.1:8080 CONNECT through proxy failed. Full reply not received: (nothing) ** WARNING **: CCC: call on already finished chain. Flags=CCC_Ended
This setup works fine under Firefox.
I tried doing a tcpdump while attempting the connection, and there is no activity.
So, while trying to research this, I ran into another issue:
2) Any time I go to a page on this site, Dillo crashes with the following:
Nav_open_url: new url='https://dillo-dev.auriga.wearlab.narkive.com/WT0JYUZq/dillo-won-t-resolve-ur...' Dns_server [0]: dillo-dev.auriga.wearlab.narkive.com is 149.248.211.108 Connecting to 149.248.211.108:443 TLS connect error: "an EOF was observed that violates the protocol" Tls_close_by_key: Avoiding SSL shutdown for: https://dillo-dev.auriga.wearlab.narkive.com/WT0JYUZq/dillo-won-t-resolve-ur... fd 6 is done and failed dillo(13689) in malloc(): write to free mem 0x60383b59140[24..31]@32 Abort trap
gdb output: Program received signal SIGABRT, Aborted. thrkill () at /tmp/-:2 2 /tmp/-: No such file or directory. in /tmp/-
This is on OpenBSD-current amd64 with LibreSSL 3.9.0, running an unmodified fresh checkout of Dillo master. Also tested on OpenBSD 7.5 with the same result.
I tested the site with: https://www.ssllabs.com/ssltest/analyze.html?d=dillo-dev.auriga.wearlab.nark...
There seem to be some handshake failures during the simulation.
This probably is not be the fault of Dillo, but maybe there is a more graceful to handle this, rather than crashing.
Even a test with curl has issues:
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to dillo-dev.auriga.wearlab.narkive.com:443
Is this site just broken/misconfigured?
Cannot reproduce with LibreSSL 3.9.2 on Linux. % LD_LIBRARY_PATH=/usr/lib/libressl src/dillo https://dillo-dev.auriga.wearlab.narkive.com/WT0JYUZq/dillo-won-t-resolve-ur... dillo_dns_init: Here we go! (threaded) TLS library: LibreSSL 3.9.2 Enabling cookies as from cookiesrc... Nav_open_url: new url='https://dillo-dev.auriga.wearlab.narkive.com/WT0JYUZq/dillo-won-t-resolve-ur...' Dns_server [0]: dillo-dev.auriga.wearlab.narkive.com is 149.248.211.108 Connecting to 149.248.211.108:443 dillo-dev.auriga.wearlab.narkive.com: TLSv1.3, cipher TLS_AES_128_GCM_SHA256 sha256 2048-bit RSA: /CN=narkive.com sha256 2048-bit RSA: /C=US/O=Let's Encrypt/CN=R11 root: /C=US/O=Internet Security Research Group/CN=ISRG Root X1 NumPendingStyleSheets=1 Dns_server [0]: narkive.net is 188.114.97.5 188.114.96.5 narkive.net: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 ecdsa-with-SHA256 256-bit EC: /CN=narkive.net ecdsa-with-SHA384 256-bit EC: /C=US/O=Google Trust Services/CN=WE1 sha256 384-bit EC: /C=US/O=Google Trust Services LLC/CN=GTS Root R4 root: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA Can you test with the latest LibreSSL 3.9.2? Is this it happening with the proxy enabled? Also, which user agent are you using in curl and Dillo? Best, Rodrigo.
Hi Rodrigo, On Tue, 27 Aug 2024 20:19:32 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
1) socks5 proxy on 127.0.0.1:8080 not working.
There is currently no support for socks5 proxies, only HTTP proxies are supported.
Thanks for confirming, the docs are not really clear on that. Could be a nice feature for the future :)
dillo-dev.auriga.wearlab.narkive.com:443
Is this site just broken/misconfigured?
Cannot reproduce with LibreSSL 3.9.2 on Linux. ... Can you test with the latest LibreSSL 3.9.2?
Is this it happening with the proxy enabled? Also, which user agent are you using in curl and Dillo?
It happens with the stock user agent and no proxy, same with curl. I'm running the latest snapshot of OpenBSD, which would have the latest version of LibreSSL. I don't care about that site, my only worry is that the error can crash Dillo. This could be an OpenBSD specific issue which wouldn't show up on Linux. Maybe this is a similar issue: https://github.com/mitmproxy/mitmproxy/issues/7128 -Alex
Hi Alex, On Tue, Aug 27, 2024 at 09:56:46PM +0200, a1ex@dismail.de wrote:
Hi Rodrigo,
On Tue, 27 Aug 2024 20:19:32 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
1) socks5 proxy on 127.0.0.1:8080 not working.
There is currently no support for socks5 proxies, only HTTP proxies are supported.
Thanks for confirming, the docs are not really clear on that. Could be a nice feature for the future :)
Yeah, unfortunately I only have two hands :-)
dillo-dev.auriga.wearlab.narkive.com:443
Is this site just broken/misconfigured?
Cannot reproduce with LibreSSL 3.9.2 on Linux. ... Can you test with the latest LibreSSL 3.9.2?
Is this it happening with the proxy enabled? Also, which user agent are you using in curl and Dillo?
It happens with the stock user agent and no proxy, same with curl. I'm running the latest snapshot of OpenBSD, which would have the latest version of LibreSSL.
I don't care about that site, my only worry is that the error can crash Dillo.
If it happens it is a bug on Dillo side as it is not handling all errors, regardless of the site. I would like to reproduce it to fix it.
This could be an OpenBSD specific issue which wouldn't show up on Linux. Maybe this is a similar issue: https://github.com/mitmproxy/mitmproxy/issues/7128
It could be, but I would first reject that is not due to mismatch of versions. The last LibreSSL as per https://www.libressl.org/ is:
The latest stable release is 3.9.2
Which should be printed in the first lines when starting Dillo:
TLS library: LibreSSL 3.9.2
If it says 3.9.0, then Dillo is not using the last release. I can try installing 3.9.0 and see if I can reproduce it with that one. Best, Rodrigo.
Hi Rodrigo, On Tue, 27 Aug 2024 23:09:42 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
dillo-dev.auriga.wearlab.narkive.com:443
Is this site just broken/misconfigured?
Cannot reproduce with LibreSSL 3.9.2 on Linux. ... Can you test with the latest LibreSSL 3.9.2?
Is this it happening with the proxy enabled? Also, which user agent are you using in curl and Dillo?
It happens with the stock user agent and no proxy, same with curl. I'm running the latest snapshot of OpenBSD, which would have the latest version of LibreSSL.
I don't care about that site, my only worry is that the error can crash Dillo.
If it happens it is a bug on Dillo side as it is not handling all errors, regardless of the site. I would like to reproduce it to fix it.
Certainly. Ideally this should not crash Dillo, no matter how obscure.
This could be an OpenBSD specific issue which wouldn't show up on Linux.
It could be, but I would first reject that is not due to mismatch of versions.
The last LibreSSL as per https://www.libressl.org/ is:
The latest stable release is 3.9.2
Which should be printed in the first lines when starting Dillo:
TLS library: LibreSSL 3.9.2
If it says 3.9.0, then Dillo is not using the last release.
I don't know why it shows that version number instead of the latest one, this is a fresh install of a recent snapshot. Anyway, I installed 3.9.2 from source and built Dillo against that. Now it reports the correct version, but the crash still happens the same. I guess we would need to hear from some other OpenBSD users to confirm if this a real issue, or if its something whacky on my end. I do have an older OpenBSD system which uses LibreSSL 3.6.0, and it does not exhibit the problem. But on 3 newer systems here the problem occurs. Here is an easy way to confirm using only OpenBSD base tools: $ ftp https://narkive.com/test Trying 149.248.211.108... TLS handshake failure: handshake failed: unexpected EOF This doesn't happen on any other site that I have seen. Maybe I should report this to the OpenBSD/LibreSSL people as well, so I'm CC'ing tb@ Regards, Alex
On Wed, Aug 28, 2024 at 01:25:21PM +0200, a1ex@dismail.de wrote:
Hi Rodrigo,
On Tue, 27 Aug 2024 23:09:42 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
dillo-dev.auriga.wearlab.narkive.com:443
Is this site just broken/misconfigured?
Cannot reproduce with LibreSSL 3.9.2 on Linux. ... Can you test with the latest LibreSSL 3.9.2?
Is this it happening with the proxy enabled? Also, which user agent are you using in curl and Dillo?
It happens with the stock user agent and no proxy, same with curl. I'm running the latest snapshot of OpenBSD, which would have the latest version of LibreSSL.
I don't care about that site, my only worry is that the error can crash Dillo.
If it happens it is a bug on Dillo side as it is not handling all errors, regardless of the site. I would like to reproduce it to fix it.
Certainly. Ideally this should not crash Dillo, no matter how obscure.
What crashes dillo?
This could be an OpenBSD specific issue which wouldn't show up on Linux.
It could be, but I would first reject that is not due to mismatch of versions.
The last LibreSSL as per https://www.libressl.org/ is:
The latest stable release is 3.9.2
Which should be printed in the first lines when starting Dillo:
TLS library: LibreSSL 3.9.2
If it says 3.9.0, then Dillo is not using the last release.
I don't know why it shows that version number instead of the latest one, this is a fresh install of a recent snapshot.
It's a bit unfortunate, but the development release on current openbsd snapshots still has 3.9.0 as the version number. It's complicated... The short story is that we can't crank to 4.0.0 because it would break the build of some important ports (e.g., rust).
Anyway, I installed 3.9.2 from source and built Dillo against that. Now it reports the correct version, but the crash still happens the same.
I guess we would need to hear from some other OpenBSD users to confirm if this a real issue, or if its something whacky on my end.
I do have an older OpenBSD system which uses LibreSSL 3.6.0, and it does not exhibit the problem. But on 3 newer systems here the problem occurs.
Here is an easy way to confirm using only OpenBSD base tools:
$ ftp https://narkive.com/test Trying 149.248.211.108... TLS handshake failure: handshake failed: unexpected EOF
I don't see this: $ ftp https://narkive.com/test Trying 149.248.211.108... Requesting https://narkive.com/test ftp: Error retrieving https://narkive.com/test: 404 Not Found $ nc -cvz narkive.com 443 Connection to narkive.com (149.248.211.108) 443 port [tcp/https] succeeded! TLS handshake negotiated TLSv1.3/TLS_AES_128_GCM_SHA256 with host narkive.com Peer name: narkive.com Subject: /CN=narkive.com Issuer: /C=US/O=Let's Encrypt/CN=R11 Valid From: Fri Jul 26 06:13:58 2024 Valid Until: Thu Oct 24 06:13:57 2024 Cert Hash: SHA256:456275146f4b2e65c16d2432ff87917a4501ddb41dcb158195255c5995abbbf1 OCSP URL: http://r11.o.lencr.org This looks all good from here.
This doesn't happen on any other site that I have seen.
Maybe I should report this to the OpenBSD/LibreSSL people as well, so I'm CC'ing tb@
What is an example of a site that you can't connect to or even crashes?
Hi, On Wed, 28 Aug 2024 13:45:04 +0200 Theo Buehler <tb@theobuehler.org> wrote:
Certainly. Ideally this should not crash Dillo, no matter how obscure.
What crashes dillo?
Opening https://narkive.com crashes Dillo for me, It doesn't happen on any other sites: Nav_open_url: new url='https://narkive.com' Dns_server [0]: narkive.com is 149.248.211.108 Connecting to 149.248.211.108:443 TLS connect error: "an EOF was observed that violates the protocol" Tls_close_by_key: Avoiding SSL shutdown for: https://narkive.com fd 9 is done and failed dillo(84242) in free(): write to free mem 0xb5efb754c40[24..31]@32 gdb: Program received signal SIGABRT, Aborted. thrkill () at /tmp/-:2 2 /tmp/-: No such file or directory. in /tmp/-
I don't know why it shows that version number instead of the latest one, this is a fresh install of a recent snapshot.
It's a bit unfortunate, but the development release on current openbsd snapshots still has 3.9.0 as the version number. It's complicated... The short story is that we can't crank to 4.0.0 because it would break the build of some important ports (e.g., rust).
Thank you for clarifying this.
$ ftp https://narkive.com/test Trying 149.248.211.108... TLS handshake failure: handshake failed: unexpected EOF
I don't see this:
$ ftp https://narkive.com/test Trying 149.248.211.108... Requesting https://narkive.com/test ftp: Error retrieving https://narkive.com/test: 404 Not Found $ nc -cvz narkive.com 443 Connection to narkive.com (149.248.211.108) 443 port [tcp/https] succeeded! TLS handshake negotiated TLSv1.3/TLS_AES_128_GCM_SHA256 with host narkive.com Peer name: narkive.com Subject: /CN=narkive.com Issuer: /C=US/O=Let's Encrypt/CN=R11 Valid From: Fri Jul 26 06:13:58 2024 Valid Until: Thu Oct 24 06:13:57 2024 Cert Hash: SHA256:456275146f4b2e65c16d2432ff87917a4501ddb41dcb158195255c5995abbbf1 OCSP URL: http://r11.o.lencr.org
This looks all good from here.
My nc output matches yours, but ftp still gets the handshake failure. Maybe it's something network specific on my end? But like I mentioned, an older OpenBSD system on my network with LibreSSL 3.6.0 does not have an issue with that site. I disabled pf just in case, but to no avail. I'm open to any clues on how to diagnose this! Regards, Alex
Nav_open_url: new url='https://narkive.com' Dns_server [0]: narkive.com is 149.248.211.108 Connecting to 149.248.211.108:443 TLS connect error: "an EOF was observed that violates the protocol" Tls_close_by_key: Avoiding SSL shutdown for: https://narkive.com fd 9 is done and failed dillo(84242) in free(): write to free mem 0xb5efb754c40[24..31]@32
ok, that's a use after free, perhaps triggered by the unexpected EOF... Can't repro even with vm.malloc_conf flags set. $ dillo https://narkive.com paths: Cannot open file '/home/tb/.dillo/dillorc': No such file or directory paths: Using /etc/dillo/dillorc paths: Cannot open file '/home/tb/.dillo/keysrc': No such file or directory paths: Using /etc/dillo/keysrc paths: Cannot open file '/home/tb/.dillo/domainrc': No such file or directory paths: Using /etc/dillo/domainrc Domain: Default accept. dillo_dns_init: Here we go! (threaded) TLS library: LibreSSL 3.9.0 Disabling cookies. paths: Cannot open file '/home/tb/.dillo/hsts_preload': No such file or directory paths: Cannot open file '/etc/dillo/hsts_preload': No such file or directory paths: Using internal defaults... Nav_open_url: new url='https://narkive.com' Dns_server [0]: narkive.com is 149.248.211.108 Connecting to 149.248.211.108:443 narkive.com: TLSv1.3, cipher TLS_AES_128_GCM_SHA256 sha256 2048-bit RSA: /CN=narkive.com sha256 2048-bit RSA: /C=US/O=Let's Encrypt/CN=R11 root: /C=US/O=Internet Security Research Group/CN=ISRG Root X1 NumPendingStyleSheets=1 Dns_server [0]: narkive.net is 188.114.96.12 188.114.97.12 2a06:98c1:3120::c 2a06:98c1:3121::c narkive.net: TLSv1.3, cipher TLS_AES_256_GCM_SHA384 ecdsa-with-SHA256 256-bit EC: /CN=narkive.net ecdsa-with-SHA384 256-bit EC: /C=US/O=Google Trust Services/CN=WE1 sha256 384-bit EC: /C=US/O=Google Trust Services LLC/CN=GTS Root R4 root: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
a_Nav_repush <<<< Nav_open_url: new url='https://narkive.com' a_Nav_expect_done: repush! Dillo: normal exit!
gdb: Program received signal SIGABRT, Aborted. thrkill () at /tmp/-:2 2 /tmp/-: No such file or directory. in /tmp/-
Please pkg_add gdb, use 'egdb dillo dillo.core and show the output of 'bt full', that might give a clue.
dillo(84242) in free(): write to free mem 0xb5efb754c40[24..31]@32
If you manage figure out what was at 0xb5efb754c40 that would help a lot.
My nc output matches yours, but ftp still gets the handshake failure. Maybe it's something network specific on my end? But like I mentioned, an older OpenBSD system on my network with LibreSSL 3.6.0 does not have an issue with that site. I disabled pf just in case, but to no avail.
No real idea at this point - sorry.
On Wed, 28 Aug 2024 15:29:57 +0200 Theo Buehler <tb@theobuehler.org> wrote:
gdb: Program received signal SIGABRT, Aborted. thrkill () at /tmp/-:2 2 /tmp/-: No such file or directory. in /tmp/-
Please pkg_add gdb, use 'egdb dillo dillo.core and show the output of 'bt full', that might give a clue.
Here is the output of 'bt full': #0 thrkill () at /tmp/-:2 No locals. #1 0x93e8d49f8f1828f2 in ?? () No symbol table info available. #2 0x00000675d78d25ab in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 sa = {__sigaction_u = {__sa_handler = 0x3000000010, __sa_sigaction = 0x3000000010}, sa_mask = 2205690992, sa_flags = 29926} mask = 4294967263 #3 0x00000675d78a13e4 in wrterror (d=0x675dc6e7678, msg=0x675d7805f67 "write to free mem %p[%zu..%zu]@%zu") at /usr/src/lib/libc/stdlib/malloc.c:378 ap = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x74e683782d70, reg_save_area = 0x74e683782c70}} saved_errno = 35 #4 0x00000675d78a2206 in validate_junk (pool=0x675dc6e7678, p=0x675d0e8d1c0, argsz=0) at /usr/src/lib/libc/stdlib/malloc.c:780 step = <optimized out> lp = 0x675d0e8d1c0 sz = <optimized out> i = <optimized out> #5 malloc_bytes (d=0x675dc6e7678, size=32) at /usr/src/lib/libc/stdlib/malloc.c:1237 bucket = <optimized out> r = <optimized out> listnum = <optimized out> bp = 0x675ba1e5f88 i = <optimized out> j = <optimized out> lp = <optimized out> k = <optimized out> p = 0x675d0e8d1c0 r = <optimized out> #6 omalloc (pool=0x675dc6e7678, sz=32, zero_fill=0) at /usr/src/lib/libc/stdlib/malloc.c:1391 caller = <error reading variable caller (Cannot access memory at address 0x0)> psz = <optimized out> p = <optimized out> #7 0x00000675d78a1689 in _libc_malloc (size=32) at /usr/src/lib/libc/stdlib/malloc.c:1545 saved_errno = 35 d = 0x675dc6e7678 r = <optimized out> #8 0x000006761b3d9918 in operator new (size=32) at /usr/src/gnu/lib/libcxx/../../../gnu/llvm/libcxx/src/new.cpp:67 p = <optimized out> #9 0x000006734c32cdd1 in ?? () No symbol table info available. #10 0x000006734c32cce5 in ?? () No symbol table info available. #11 0x000006734c32c933 in ?? () No symbol table info available. #12 0x000006734c32b4e2 in ?? () No symbol table info available. #13 0x000006734c32c7a9 in ?? () No symbol table info available. #14 0x000006734c32b31e in ?? () No symbol table info available. #15 0x000006734c32082d in ?? () No symbol table info available. #16 0x000006734c297b5c in ?? () No symbol table info available. #17 0x000006754d2f179b in fl_fix_focus() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #18 0x000006754d2f1ca7 in Fl::handle_(int, Fl_Window*) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #19 0x000006754d36483b in fl_handle(_XEvent const&) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #20 0x000006754d360f40 in do_queued_events() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #21 0x000006754d360e88 in fl_wait(double) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #23 0x000006754d2f0c4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #24 0x000006734c2941d5 in ?? () No symbol table info available. #25 0x000006734c2932bb in ?? () No symbol table info available. #26 0x0000000000000000 in ?? () No symbol table info available.
On Wed, Aug 28, 2024 at 03:56:55PM +0200, a1ex@dismail.de wrote:
On Wed, 28 Aug 2024 15:29:57 +0200 Theo Buehler <tb@theobuehler.org> wrote:
gdb: Program received signal SIGABRT, Aborted. thrkill () at /tmp/-:2 2 /tmp/-: No such file or directory. in /tmp/-
Please pkg_add gdb, use 'egdb dillo dillo.core and show the output of 'bt full', that might give a clue.
Here is the output of 'bt full':
Thanks, that doesn't help us further as such. I have enabled DEBUG_PACKAGES in dillo, which unfortunately wasn't done before. Once the debug-dillo package is available (will be a few days), we might get some more insight from a backtrace with symbols... If you have a ports tree set up (with doas, etc) you can build and install it yourself: $ cd /usr/ports/www/dillo $ grep DEBUG Makefile # ensure that your tree's up-to-date DEBUG_PACKAGES = ${BUILD_PACKAGES} $ make FETCH_PACKAGES= prepare $ make package $ make INSTALL_DEBUG_PACKAGES=yes install
Hi, On Wed, 28 Aug 2024 16:09:25 +0200 Theo Buehler <tb@theobuehler.org> wrote:
Here is the output of 'bt full':
Thanks, that doesn't help us further as such.
I have enabled DEBUG_PACKAGES in dillo, which unfortunately wasn't done before. Once the debug-dillo package is available (will be a few days), we might get some more insight from a backtrace with symbols...
If you have a ports tree set up (with doas, etc) you can build and install it yourself:
I have built the debug package as advised, here is the result: #0 thrkill () at /tmp/-:2 No locals. #1 0x4ef74ca4d7368dd1 in ?? () No symbol table info available. #2 0x000001049f2745ab in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 sa = {__sigaction_u = {__sa_handler = 0x3000000010, __sa_sigaction = 0x3000000010}, sa_mask = 90789216, sa_flags = 29661} mask = 4294967263 #3 0x000001049f2433e4 in wrterror (d=0x1054e1c1000, msg=0x1049f1a7f67 "write to free mem %p[%zu..%zu]@%zu") at /usr/src/lib/libc/stdlib/malloc.c:378 ap = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x73dd05695660, reg_save_area = 0x73dd05695560}} saved_errno = 35 #4 0x000001049f244206 in validate_junk (pool=0x1054e1c1000, p=0x1050ccc5980, argsz=0) at /usr/src/lib/libc/stdlib/malloc.c:780 step = <optimized out> lp = 0x1050ccc5980 sz = <optimized out> i = <optimized out> #5 malloc_bytes (d=0x1054e1c1000, size=32) at /usr/src/lib/libc/stdlib/malloc.c:1237 bucket = <optimized out> r = <optimized out> listnum = <optimized out> bp = 0x1050957bf18 i = <optimized out> j = <optimized out> lp = <optimized out> k = <optimized out> p = 0x1050ccc5980 r = <optimized out> #6 omalloc (pool=0x1054e1c1000, sz=32, zero_fill=0) at /usr/src/lib/libc/stdlib/malloc.c:1391 caller = <error reading variable caller (Cannot access memory at address 0x0)> psz = <optimized out> p = <optimized out> #7 0x000001049f243689 in _libc_malloc (size=32) at /usr/src/lib/libc/stdlib/malloc.c:1545 saved_errno = 35 d = 0x1054e1c1000 r = <optimized out> #8 0x000001047d040251 in XCreateRegion () from /usr/X11R6/lib/libX11.so.18.2 No symbol table info available. #9 0x00000104c101d2b2 in Fl_Graphics_Driver::clip_box(int, int, int, int, int&, int&, int&, int&) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #10 0x00000102794e10fe in dw::fltk::FltkViewBase::draw(dw::core::Rectangle const*, dw::fltk::FltkViewBase::DrawType) () No symbol table info available. #11 0x00000102794e0fdd in dw::fltk::FltkViewBase::draw() () No symbol table info available. #12 0x00000102794e33f0 in dw::fltk::FltkViewport::draw_area(void*, int, int, int, int) () No symbol table info available. #13 0x00000104c1020bdc in fl_scroll(int, int, int, int, int, int, void (*)(void*, int, int, int, int), void*) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #14 0x00000102794e3635 in dw::fltk::FltkViewport::draw() () No symbol table info available. #15 0x00000104c0fad2cb in Fl_Group::draw_children() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #16 0x00000104c0fad62d in Fl_Group::update_child(Fl_Widget&) const () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #17 0x00000104c0fad2cb in Fl_Group::draw_children() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #18 0x00000104c0fa557f in Fl_Double_Window::flush(int) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #19 0x00000104c0f91bac in Fl::flush() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #20 0x00000104c0f91a49 in Fl::wait(double) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #21 0x00000104c0f91c4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #22 0x0000010279455f95 in main () No symbol table info available. That is from a 'bt full' like before. If there is something else that needs to be done, please let me know. Regarding what you said before:
dillo(84242) in free(): write to free mem 0xb5efb754c40[24..31]@32
If you manage figure out what was at 0xb5efb754c40 that would help a lot.
Is there a practical way to do that? I would try, but not sure how. Thanks! -Alex
Hi, I think there are two problems here: 1) The narkive server is sending you an EOF but not us. 2) When that happens Dillo crashes. You may be able to get some info on where it is failing by building Dillo with the address sanitizer enabled: $ git clone https://github.com/dillo-browser/dillo $ cd dillo $ ./autogen.sh $ mkdir build $ cd build $ ../configure 'CFLAGS=-Og -g -fsanitize=address' 'CXXFLAGS=-Og -g -fsanitize=address' $ make $ src/dillo https://narkive.com Then send *all the lines of the output*. I may be able to emulate an EOF and crash my own Dillo just to reproduce the issue with this information. To debug the TLS traffic you may want to get a network trace with Wireshark so we can compare it. Best, Rodrigo. On Wed, Aug 28, 2024 at 05:45:37PM +0200, a1ex@dismail.de wrote:
Hi,
On Wed, 28 Aug 2024 16:09:25 +0200 Theo Buehler <tb@theobuehler.org> wrote:
Here is the output of 'bt full':
Thanks, that doesn't help us further as such.
I have enabled DEBUG_PACKAGES in dillo, which unfortunately wasn't done before. Once the debug-dillo package is available (will be a few days), we might get some more insight from a backtrace with symbols...
If you have a ports tree set up (with doas, etc) you can build and install it yourself:
I have built the debug package as advised, here is the result:
#0 thrkill () at /tmp/-:2 No locals. #1 0x4ef74ca4d7368dd1 in ?? () No symbol table info available. #2 0x000001049f2745ab in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 sa = {__sigaction_u = {__sa_handler = 0x3000000010, __sa_sigaction = 0x3000000010}, sa_mask = 90789216, sa_flags = 29661} mask = 4294967263 #3 0x000001049f2433e4 in wrterror (d=0x1054e1c1000, msg=0x1049f1a7f67 "write to free mem %p[%zu..%zu]@%zu") at /usr/src/lib/libc/stdlib/malloc.c:378 ap = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x73dd05695660, reg_save_area = 0x73dd05695560}} saved_errno = 35 #4 0x000001049f244206 in validate_junk (pool=0x1054e1c1000, p=0x1050ccc5980, argsz=0) at /usr/src/lib/libc/stdlib/malloc.c:780 step = <optimized out> lp = 0x1050ccc5980 sz = <optimized out> i = <optimized out> #5 malloc_bytes (d=0x1054e1c1000, size=32) at /usr/src/lib/libc/stdlib/malloc.c:1237 bucket = <optimized out> r = <optimized out> listnum = <optimized out> bp = 0x1050957bf18 i = <optimized out> j = <optimized out> lp = <optimized out> k = <optimized out> p = 0x1050ccc5980 r = <optimized out> #6 omalloc (pool=0x1054e1c1000, sz=32, zero_fill=0) at /usr/src/lib/libc/stdlib/malloc.c:1391 caller = <error reading variable caller (Cannot access memory at address 0x0)> psz = <optimized out> p = <optimized out> #7 0x000001049f243689 in _libc_malloc (size=32) at /usr/src/lib/libc/stdlib/malloc.c:1545 saved_errno = 35 d = 0x1054e1c1000 r = <optimized out> #8 0x000001047d040251 in XCreateRegion () from /usr/X11R6/lib/libX11.so.18.2 No symbol table info available. #9 0x00000104c101d2b2 in Fl_Graphics_Driver::clip_box(int, int, int, int, int&, int&, int&, int&) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #10 0x00000102794e10fe in dw::fltk::FltkViewBase::draw(dw::core::Rectangle const*, dw::fltk::FltkViewBase::DrawType) () No symbol table info available. #11 0x00000102794e0fdd in dw::fltk::FltkViewBase::draw() () No symbol table info available. #12 0x00000102794e33f0 in dw::fltk::FltkViewport::draw_area(void*, int, int, int, int) () No symbol table info available. #13 0x00000104c1020bdc in fl_scroll(int, int, int, int, int, int, void (*)(void*, int, int, int, int), void*) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #14 0x00000102794e3635 in dw::fltk::FltkViewport::draw() () No symbol table info available. #15 0x00000104c0fad2cb in Fl_Group::draw_children() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #16 0x00000104c0fad62d in Fl_Group::update_child(Fl_Widget&) const () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #17 0x00000104c0fad2cb in Fl_Group::draw_children() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #18 0x00000104c0fa557f in Fl_Double_Window::flush(int) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #19 0x00000104c0f91bac in Fl::flush() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #20 0x00000104c0f91a49 in Fl::wait(double) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #21 0x00000104c0f91c4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #22 0x0000010279455f95 in main () No symbol table info available.
That is from a 'bt full' like before. If there is something else that needs to be done, please let me know.
Regarding what you said before:
dillo(84242) in free(): write to free mem 0xb5efb754c40[24..31]@32
If you manage figure out what was at 0xb5efb754c40 that would help a lot.
Is there a practical way to do that? I would try, but not sure how.
Thanks!
-Alex _______________________________________________ Dillo-dev mailing list -- dillo-dev@mailman3.com To unsubscribe send an email to dillo-dev-leave@mailman3.com
Hi, On Wed, 28 Aug 2024 19:12:43 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
You may be able to get some info on where it is failing by building Dillo with the address sanitizer enabled:
$ git clone https://github.com/dillo-browser/dillo $ cd dillo $ ./autogen.sh $ mkdir build $ cd build $ ../configure 'CFLAGS=-Og -g -fsanitize=address' 'CXXFLAGS=-Og -g -fsanitize=address' $ make $ src/dillo https://narkive.com
::HashSet(bool, int) () No symbol table info available. #11 0x00000192ef94bec5 in dw::core::StackingProcessingContext::StackingProcessingContext() () No symbol table info available. #12 0x00000192ef94bb13 in dw::core::GettingWidgetAtPointContext::GettingWidgetAtPointContext() () No symbol table info available. #13 0x00000192ef94a6c2 in dw::core::Layout::getWidgetAtPoint(int, int) () No symbol table info available. #14 0x00000192ef94b989 in dw::core::Layout::moveToWidgetAtPoint(int, int, dw::core::ButtonState) () No symbol table info available. #15 0x00000192ef94a4fe in dw::core::Layout::motionNotify(dw::core::View*, int, int, dw::core::ButtonState) () No symbol table info available. #16 0x00000192ef93fa0d in dw::fltk::FltkViewBase::handle(int) () No symbol
That doesn't seem to work: $ ../configure 'CFLAGS=-Og -g -fsanitize=address' 'CXXFLAGS=-Og -g -fsanitize=address' checking build system type... x86_64-unknown-openbsd7.6 [...] configure: error: C compiler cannot create executables See `config.log' for more details config.log: [...] configure:4670: checking whether the C compiler works configure:4692: cc -Og -g -fsanitize=address -I/usr/local/include -I/usr/X11R6/include -L/usr/local/lib -L/usr/X11R6/lib conftest.c >&5 cc: error: unsupported option '-fsanitize=address' for target 'amd64-unknown-openbsd7.6' [...] I also tried it with gcc, but also no luck: configure:4670: checking whether the C compiler works configure:4692: egcc -Og -g -fsanitize=address -I/usr/local/include -I/usr/X11R6/include -L/usr/local/lib -L/usr/X11R6/lib conftest.c >&5 ld: error: unable to find library -lasan Then I tried this: $ MALLOC_OPTIONS=D dillo result: Nav_open_url: new url='https://narkive.com' Dns_server [0]: narkive.com is 149.248.211.108 Connecting to 149.248.211.108:443 TLS connect error: "an EOF was observed that violates the protocol" Tls_close_by_key: Avoiding SSL shutdown for: https://narkive.com fd 6 is done and failed dillo(76315) in malloc(): write to free chunk 0x1957a5e82c0[24..31]@32 allocated at /usr/lib/libc++.so.10.0 0x8b918 (preceding chunk 0x1957a5e82a0 allocated at /usr/local/lib/libcrypto.so.53.0 0x1a7f51) Abort trap (core dumped) So now we have a reference to libcrypto. Here is the backtrace, also with some new info: #0 thrkill () at /tmp/-:2 No locals. #1 0xf3ab3815f99febfa in ?? () No symbol table info available. #2 0x000001956d60a5ab in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 sa = {__sigaction_u = {__sa_handler = 0x3000000010, __sa_sigaction = 0x3000000010}, sa_mask = 3661176352, sa_flags = 31051} mask = 4294967263 #3 0x000001956d5d93e4 in wrterror (d=0x195325a97a8, msg=0x1956d53c0ad "write to free chunk %p[%zu..%zu]@%zu allocated at %s (preceding chunk %p allocated at %s%s)") at /usr/src/lib/libc/stdlib/malloc.c:378 ap = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x794bda391f40, reg_save_area = 0x794bda391e20}} saved_errno = 35 #4 0x000001956d5df052 in print_chunk_details (pool=0x195325a97a8, p=0x1957a5e82c0, sz=32, index=<optimized out>) at /usr/src/lib/libc/stdlib/malloc.c:2433 buf1 = "/usr/lib/libc++.so.10.0 0x8b918\000\310pam\225\001\000\000\300\337Z1\225\001\000\000\310pam\225\001\000\000\000\000\000\000\000\000\000\000x\322\020\027\225\001\000\000\240\371`z\225\001\000\000\240\371`z\225\001\000\000\250\227Z2\225\001\000\000\000\000\000\000\000\000\000\000IT\327|\370V\347W0 9\332Ky\000\000\000\000\000\000\000\000\000" buf2 = "/usr/local/lib/libcrypto.so.53.0 0x1a7f51", '\000' <repeats 16 times>, "\220c=\225\001\000\000\300\364`z\225\001\000\000\b\000\000\000\000\000\000\000@h=\366\224\001\000\000\272\fе\224\351\327]\310pam\225\001\000\000\253\305Sm\225\001\000\000\270tam\225\001\0-00\000\000\000\000\000\000\000\000" msg = <optimized out> r = <optimized out> chunkinfo = 0x195576c5f88 chunknum = <optimized out> btnode = <optimized out> frame = 0 #5 0x000001956d5da1dd in validate_junk (pool=0x195325a97a8, p=0x1957a5e82c0, argsz=0) at /usr/src/lib/libc/stdlib/malloc.c:777 step = <optimized out> lp = 0x1957a5e82c0 sz = <optimized out> i = 1741296686955 #6 malloc_bytes (d=0x195325a97a8, size=32) at /usr/src/lib/libc/stdlib/malloc.c:1237 bucket = <optimized out> r = <optimized out> listnum = <optimized out> bp = 0x195576c5f88 i = <optimized out> j = <optimized out> lp = <optimized out> k = <optimized out> p = 0x1957a5e82c0 r = <optimized out> #7 omalloc (pool=0x195325a97a8, sz=32, zero_fill=0) at /usr/src/lib/libc/stdlib/malloc.c:1391 caller = <error reading variable caller (Cannot access memory at address 0x0)> psz = <optimized out> p = <optimized out> #8 0x000001956d5d9689 in _libc_malloc (size=32) at /usr/src/lib/libc/stdlib/malloc.c:1545 saved_errno = 35 d = 0x195325a97a8 r = <optimized out> #9 0x000001956bbc0918 in operator new (size=32) at /usr/src/gnu/lib/libcxx/../../../gnu/llvm/libcxx/src/new.cpp:67 p = <optimized out> #10 0x00000192ef94bfb1 in lout::container::typed::HashSet<lout::object::TypedPointer<dw::core::Widget> table info available. #17 0x00000192ef8b792c in UI::handle(int) () No symbol table info available. #18 0x0000019517063404 in send(int, Fl_Widget*, Fl_Window*) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #19 0x00000195170630da in Fl::handle_(int, Fl_Window*) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #20 0x00000195170d1f7c in do_queued_events() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #21 0x00000195170d1e88 in fl_wait(double) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #22 0x0000019517061a6e in Fl::wait(double) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #23 0x0000019517061c4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #24 0x00000192ef8b3f95 in main () No symbol table info available. Hope this helps! Thanks, Alex
On Wed, Aug 28, 2024 at 08:14:20PM +0200, a1ex@dismail.de wrote:
Hi,
On Wed, 28 Aug 2024 19:12:43 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
You may be able to get some info on where it is failing by building Dillo with the address sanitizer enabled:
$ git clone https://github.com/dillo-browser/dillo $ cd dillo $ ./autogen.sh $ mkdir build $ cd build $ ../configure 'CFLAGS=-Og -g -fsanitize=address' 'CXXFLAGS=-Og -g -fsanitize=address' $ make $ src/dillo https://narkive.com
That doesn't seem to work:
$ ../configure 'CFLAGS=-Og -g -fsanitize=address' 'CXXFLAGS=-Og -g -fsanitize=address' checking build system type... x86_64-unknown-openbsd7.6 [...] configure: error: C compiler cannot create executables See `config.log' for more details
yes, asan isn't supported on openbsd.
dillo(76315) in malloc(): write to free chunk 0x1957a5e82c0[24..31]@32 allocated at /usr/lib/libc++.so.10.0 0x8b918 (preceding chunk 0x1957a5e82a0 allocated at /usr/local/lib/libcrypto.so.53.0 0x1a7f51)
what's the output of addr2line -e /usr/lib/libc++.so.10.0 0x8b918 and addr2line -e /usr/local/lib/libcrypto.so.53.0 0x1a7f51 on your system?
On Wed, 28 Aug 2024 20:22:37 +0200 Theo Buehler <tb@theobuehler.org> wrote:
dillo(76315) in malloc(): write to free chunk 0x1957a5e82c0[24..31]@32 allocated at /usr/lib/libc++.so.10.0 0x8b918 (preceding chunk 0x1957a5e82a0 allocated at /usr/local/lib/libcrypto.so.53.0 0x1a7f51)
what's the output of
addr2line -e /usr/lib/libc++.so.10.0 0x8b918
/usr/src/gnu/lib/libcxx/../../../gnu/llvm/libcxx/src/new.cpp:67
and
addr2line -e /usr/local/lib/libcrypto.so.53.0 0x1a7f51
stack/stack.c:128 I am also including part of a ktrace of the crash, just in case that would be useful: 57506 dillo GIO fd 1 wrote 34 bytes "Connecting to 149.248.211.108:443 " 57506 dillo RET write 34/0x22 57506 dillo CALL connect(6,0x759b98292280,16) 57506 dillo STRU struct sockaddr { AF_INET, 149.248.211.108:443 } 57506 dillo RET connect -1 errno 36 Operation now in progress 57506 dillo CALL futex(0xc4d868bc00,0x82<FUTEX_WAKE|FUTEX_PRIVATE_FLAG>,2147483647,0,0) 57506 dillo RET futex 0 57506 dillo CALL sigprocmask(SIG_BLOCK,0<>) 57506 dillo RET sigprocmask 0<> 57506 dillo CALL poll(0x759b982923c8,1,INFTIM) 57506 dillo STRU struct pollfd { fd=5, events=0x5<POLLIN|POLLOUT>, revents=0x5<POLLIN|POLLOUT> } 57506 dillo RET poll 1 57506 dillo CALL recvmsg(5,0x759b98292280,0) 57506 dillo GIO fd 5 read 32 bytes "\^N\0l\b\^N\0\M^@\^B\0\0>\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0" 57506 dillo STRU struct msghdr { name=0x0, namelen=0, iov=0x759b98292270, iovlen=1, control=0x759b98292220, controllen=0, flags=0x80<MSG_DONTWAIT> } 57506 dillo STRU struct iovec { base=0xc554d1a04c, len=4064 } 57506 dillo RET recvmsg 32/0x20 57506 dillo CALL futex(0xc4d86b3ef0,0x82<FUTEX_WAKE|FUTEX_PRIVATE_FLAG>,1,0,0) 57506 dillo RET futex 0 57506 dillo CALL writev(5,0x759b98292470,3) 57506 dillo STRU struct iovec [3] { base=0xc53d099000, len=504 } { base=0x0, len=0 } { base=0xc504b50156, len=0 } 57506 dillo GIO fd 5 wrote 504 bytes "8\^B\^E\0\^E\0\M^@\^B\^D\0\b\0\M^Y\M^Y\M^Y\0\0\0\0\0;\^C\^E\0\^E\0\M^@\^B\0\0\0\0\ \0\0\M-1\^C\M-k\^D\^T\0;\^C\^E\0\^E\0\M^@\^B\0\0\0\0\^A\0\M-2\^C\M-i\^D\^R\0;\^C\ \^E\0\^E\0\M^@\^B\0\0\0\0\^A\0\M-2\^C\M-i\^D\^R\08\0\^D\0\^E\0\M^@\^B\^D\0\0\0qqq\ \0B\0\a\0\^N\0\M^@\^B\^E\0\M^@\^B\0\0\M-D\^C\M-j\^D\M-D\^C\M-j\^D\M-C\^C\M-j\^D\ \M-1\^C8\M^@\^D\0\^E\0\M^@\^B\^D\0\0\0\0\0\0\0B\0\a\0\^N\0\M^@\^B\^E\0\M^@\^B\0\0\ \M-1\^C\M-i\^D\M-1\^C\0\0\M-C\^C\0\0\M-2\^C8C\^D\0\^E\0\M^@\^B\^D\0\0\0\^A\^A\^A\0\ F\0\^E\0\^N\0\M^@\^B\^E\0\M^@\^B\^A\0\M-2\^C\M-i\^D\^R\0\M^K\a\^B\0\a\^A\M^@\^B\ \M^K\^D\^E\0\b\^A\M^@\^B\^N\0\M^@\^B)\0\0\0\0\0\0\0\M^K\^F\^E\0\b\^A\M^@\^B\0\0\0\ \0\^A\0\M-2\^C\M-i\^D\^R\0\M^K\^T\^_\0\^B\0\M^@\^B\^A\0\0\0&\0\0\0\b\0\f\0\0\0\v\0\ \0\0\0\0\0\0\0\^E\0\0\0\0\0i\M-]\M-~\M-fz\^B\0d\M-nY W\M-pn\0\M-\o\0\0\0z\ \M-L\b\M-~0\0\0\0\^XI\^_\M^?\^\\0\0\0\0\0\^_\M^?\^\\0\0\0\0\0\r\M^?+\0\0\0\0\0\0\ \M-g_\0\0\0`\M-T\0z\M-`0\0%\M-X\M^I\0\^F\M^R\M-}\M-v\M^?\M-# \0\0\0 ,\^O\0\0\ \M^K\^X\^R\0\^C\M-U\M-b\0(\0\M^@\^B\b\^A\M^@\^B$\0\0\0\^B\0\M^@\^B\0\0\0\0\^R\0\0\ \0\^B\0\M-@\^C&\0t\^Bj\^B\M-2\^B\M-d\^A\^F\^B\M-2\^BC\^Bj\^B1\^B\^C\09\^Bt\^B\M-'\ \^B\M-2\^BP\^DP\^DP\^D;\^C\^E\0\^E\0\M^@\^B\0\0\0\0\^A\0\M-2\^C\M-i\^D\^R\0;\^C\^E\ \0\^E\0\M^@\^B\0\0\0\0\0\0\M-1\^C\M-k\^D\^T\0\M^Q\^C\^D\0\^A\0\0\0\^D\0\M^@\^B\^C\ \0\0\0" 57506 dillo RET writev 504/0x1f8 57506 dillo CALL futex(0xc4d86ad1a0,0x82<FUTEX_WAKE|FUTEX_PRIVATE_FLAG>,2147483647,0,0) 57506 dillo RET futex 0 57506 dillo CALL futex(0xc4d86b3ef0,0x82<FUTEX_WAKE|FUTEX_PRIVATE_FLAG>,1,0,0) 57506 dillo RET futex 0 57506 dillo CALL recvmsg(5,0x759b98292370,0) 57506 dillo RET recvmsg -1 errno 35 Resource temporarily unavailable 57506 dillo CALL recvmsg(5,0x759b982920d0,0) 57506 dillo RET recvmsg -1 errno 35 Resource temporarily unavailable 57506 dillo CALL recvmsg(5,0x759b98292370,0) 57506 dillo RET recvmsg -1 errno 35 Resource temporarily unavailable 57506 dillo CALL select(7,0x759b98292390,0x759b98292410,0x759b98292490,0) 57506 dillo STRU struct fd_set { 3,5 } 57506 dillo STRU struct fd_set { 6 } 57506 dillo STRU struct fd_set { } 57506 dillo STRU struct fd_set { } 57506 dillo STRU struct fd_set { 6 } 57506 dillo STRU struct fd_set { } 57506 dillo RET select 1 57506 dillo CALL kbind(0x759b98292288,24,0xb28d566424727b4) 57506 dillo RET kbind 0 57506 dillo CALL getsockopt(6,SOL_SOCKET,SO_ERROR,0x759b98292358,0x759b9829235c) 57506 dillo RET getsockopt 0 57506 dillo CALL kbind(0x759b98292248,24,0xb28d566424727b4) 57506 dillo RET kbind 0 57506 dillo CALL kbind(0x759b98292248,24,0xb28d566424727b4) 57506 dillo RET kbind 0 57506 dillo CALL kbind(0x759b98292248,24,0xb28d566424727b4) 57506 dillo RET kbind 0 57506 dillo CALL kbind(0x759b98292218,24,0xb28d566424727b4) 57506 dillo RET kbind 0 57506 dillo CALL kbind(0x759b98292248,24,0xb28d566424727b4) 57506 dillo RET kbind 0 57506 dillo CALL kbind(0x759b982911d8,24,0xb28d566424727b4) 57506 dillo RET kbind 0 57506 dillo CALL mmap(0,0x5000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0) 57506 dillo RET mmap 846576910336/0xc51bea8000 57506 dillo CALL write(6,0xc48c3b0640,0x123) 57506 dillo GIO fd 6 wrote 291 bytes "\^V\^C\^C\^A\^^\^A\0\^A\^Z\^C\^C\M-=\^[j 2\M-r_\M-5\M-Z*|^Bm\M-+\M-I\M-LD\M^G]-e\^Xa\M^H\M-0\^]6\M-J'g\M-k \M^^\M-n\M-S\M-D\ \M-B\M-}\^QWyqV\M-d,\M^K\M^L\M-/\M-l\f< \M--~\M-ax\^V,^`\M^Y\M-FV\M-]\0V\^S\^B\^S\^C\^S\^A\M-@0\M-@,\M-@(\M-@$\M-@\^T\M-@ \0\M^_\0k\09\M-L\M-)\M-L\M-(\M-L\M-*\0\M-D\0\M^H\0\M^]\0=\0005\0\M-@\0\M^D\M-@/\ \M-@+\M-@'\M-@#\M-@\^S\M-@ \0\M^^\0g\0003\0\M->\0E\0\M^\\0<\0/\0\M-:\0A\M-@\ \^R\M-@\b\0\^V\0 \0\M^?\^A\0\0{\0\0\0\^P\0\^N\0\0\vnarkive.com\0\v\0\^B\^A\0\0\r\0\^X\0\^V\b\^F\^F\ \^A\^F\^C\b\^E\^E\^A\^E\^C\b\^D\^D\^A\^D\^C\^B\^A\^B\^C\0 \0 \0\b\0\^]\0\^W\0\^X\0\^Y\0003\0&\0$\0\^]\0 \^O\M-+\r\M-k$\M-f\^\\f]K\M-Fr\M->&\M-s\ a \M^Y\M-0\M-]F`NU\M^X(\^XT\M-MTQ5\0+\0\^E\^D\^C\^D\^C\^C\0#\0\0" 57506 dillo RET write 291/0x123 57506 dillo CALL read(6,0xc48c3a58b0,0x5) 57506 dillo RET read -1 errno 35 Resource temporarily unavailable 57506 dillo CALL kbind(0x759b982911d8,24,0xb28d566424727b4) 57506 dillo RET kbind 0 57506 dillo CALL futex(0xc4d868bc00,0x82<FUTEX_WAKE|FUTEX_PRIVATE_FLAG>,2147483647,0,0) 57506 dillo RET futex 0 57506 dillo CALL sigprocmask(SIG_BLOCK,0<>) 57506 dillo RET sigprocmask 0<> 57506 dillo CALL poll(0x759b982923c8,1,INFTIM) 57506 dillo STRU struct pollfd { fd=5, events=0x5<POLLIN|POLLOUT>, revents=0x4<POLLOUT> } 57506 dillo RET poll 1 57506 dillo CALL writev(5,0x759b98292470,3) 57506 dillo STRU struct iovec [3] { base=0xc53d099000, len=508 } { base=0x0, len=0 } { base=0xc504b50156, len=0 } 57506 dillo GIO fd 5 wrote 508 bytes "8\^B\^E\0\^E\0\M^@\^B\^D\0\b\0\M^Y\M^Y\M^Y\0\0\0\0\0;\^C\^E\0\^E\0\M^@\^B\0\0\0\0\ \0\0\M-1\^C\M-k\^D\^T\0;\^C\^E\0\^E\0\M^@\^B\0\0\0\0\^A\0\M-2\^C\M-i\^D\^R\0;\^C\ \^E\0\^E\0\M^@\^B\0\0\0\0\^A\0\M-2\^C\M-i\^D\^R\08\0\^D\0\^E\0\M^@\^B\^D\0\0\0qqq\ \0B\0\a\0\^N\0\M^@\^B\^E\0\M^@\^B\0\0\M-D\^C\M-j\^D\M-D\^C\M-j\^D\M-C\^C\M-j\^D\ \M-1\^C8\M^@\^D\0\^E\0\M^@\^B\^D\0\0\0\0\0\0\0B\0\a\0\^N\0\M^@\^B\^E\0\M^@\^B\0\0\ \M-1\^C\M-i\^D\M-1\^C\0\0\M-C\^C\0\0\M-2\^C8C\^D\0\^E\0\M^@\^B\^D\0\0\0\^A\^A\^A\0\ F\0\^E\0\^N\0\M^@\^B\^E\0\M^@\^B\^A\0\M-2\^C\M-i\^D\^R\0\M^K\a\^B\0\b\^A\M^@\^B\ \M^K\^D\^E\0 \^A\M^@\^B\^N\0\M^@\^B)\0\0\0\0\0\0\0\M^K\^F\^E\0 \^A\M^@\^B\ \0\0\0\0\^A\0\M-2\^C\M-i\^D\^R\0\M^K\^T\^Y\0\^B\0\M^@\^B\^A\0\0\0\M-<\^B\0\0\a\0\ \0\M^?\M^?\b\0 \0\0\0J/\0\0\0T%\0\M-7s\0\0\0\M-O[\0\M-7s\0\0\0\M-O[\0\M-7\ s\0\0\0\M-O[\0\M-7s\0\0\0\M-P[\0\M-2\^?\0\0\^A\M-i[\0\M^H\M-S*\^Dy\M-q[\0\^W\M-O\ \M^?\M-kp\M-C[\0\0\0\^U\^C\0\0\0\0\M^K\^X\^Y\0\^C%\M-X\M^I(\0\M^@\^B \^A\M^@\^B\ $\0\0\0\^B\0\M^@\^B\0\0\0\0 \0\0\0\^B\0\M-@\^C\M-F\0\^U\^B\^F\^B\M-<\^B\M^]\^B\^U\ \^B\^C\0\^F\^Bt\^Bj\^Bj\^B\^U\^B\^F\^B\M-2\^BC\^Bt\^Bj\^B\^C\0j\^B\^U\^B1\^Bt\^B\ \M-2\^BC\^B\M-d\^A\M-2\^BC\^Bt\^Bj\^BP\^DP\^DP\^D;\^C\^E\0\^E\0\M^@\^B\0\0\0\0\^A\ \0\M-2\^C\M-i\^D\^R\0;\^C\^E\0\^E\0\M^@\^B\0\0\0\0\0\0\M-1\^C\M-k\^D\^T\0\M^Q\^C\ \^D\0\^A\0\0\0\^D\0\M^@\^B\^C\0\0\0" 57506 dillo RET writev 508/0x1fc 57506 dillo CALL futex(0xc4d86ad1a0,0x82<FUTEX_WAKE|FUTEX_PRIVATE_FLAG>,2147483647,0,0) 57506 dillo RET futex 0 57506 dillo CALL futex(0xc4d86b3ef0,0x82<FUTEX_WAKE|FUTEX_PRIVATE_FLAG>,1,0,0) 57506 dillo RET futex 0 57506 dillo CALL recvmsg(5,0x759b98292370,0) 57506 dillo RET recvmsg -1 errno 35 Resource temporarily unavailable 57506 dillo CALL select(7,0x759b98292390,0x759b98292410,0x759b98292490,0) 57506 dillo STRU struct fd_set { 3,5,6 } 57506 dillo STRU struct fd_set { } 57506 dillo STRU struct fd_set { } 57506 dillo STRU struct fd_set { 5 } 57506 dillo STRU struct fd_set { } 57506 dillo STRU struct fd_set { } 57506 dillo RET select 1 57506 dillo CALL recvmsg(5,0x759b982920d0,0) 57506 dillo GIO fd 5 read 32 bytes "\^C$\M-/\bZ\^C\0\^A\M-G\^B\0\0\^D\0\M^@\^B\0\0\0\0j\^Fi\0 \^A\^R\0\0\0\^A\0" 57506 dillo STRU struct msghdr { name=0x0, namelen=0, iov=0x759b982920c0, iovlen=1, control=0x759b98292070, controllen=0, flags=0x80<MSG_DONTWAIT> } 57506 dillo STRU struct iovec { base=0xc554d1a04c, len=4064 } 57506 dillo RET recvmsg 32/0x20 57506 dillo CALL futex(0xc4d86b3ef0,0x82<FUTEX_WAKE|FUTEX_PRIVATE_FLAG>,1,0,0) 57506 dillo RET futex 0 57506 dillo CALL recvmsg(5,0x759b982920d0,0) 57506 dillo RET recvmsg -1 errno 35 Resource temporarily unavailable 57506 dillo CALL recvmsg(5,0x759b98291ed0,0) 57506 dillo RET recvmsg -1 errno 35 Resource temporarily unavailable 57506 dillo CALL recvmsg(5,0x759b982920d0,0) 57506 dillo RET recvmsg -1 errno 35 Resource temporarily unavailable 57506 dillo CALL recvmsg(5,0x759b98292370,0) 57506 dillo RET recvmsg -1 errno 35 Resource temporarily unavailable 57506 dillo CALL select(7,0x759b98292390,0x759b98292410,0x759b98292490,0) 57506 dillo STRU struct fd_set { 3,5,6 } 57506 dillo STRU struct fd_set { } 57506 dillo STRU struct fd_set { } 57506 dillo STRU struct fd_set { 6 } 57506 dillo STRU struct fd_set { } 57506 dillo STRU struct fd_set { } 57506 dillo RET select 1 57506 dillo CALL read(6,0xc48c3a58b0,0x5) 57506 dillo RET read 0 57506 dillo CALL write(1,0xc4e11d5000,0x44) 57506 dillo GIO fd 1 wrote 68 bytes "TLS connect error: "an EOF was observed that violates the protocol" " 57506 dillo RET write 68/0x44 57506 dillo CALL write(1,0xc4e11d5000,0x41) 57506 dillo GIO fd 1 wrote 65 bytes "Tls_close_by_key: Avoiding SSL shutdown for: https://narkive.com " 57506 dillo RET write 65/0x41 57506 dillo CALL kbind(0x759b982911d8,24,0xb28d566424727b4) 57506 dillo RET kbind 0 57506 dillo CALL write(1,0xc4e11d5000,0x18) 57506 dillo GIO fd 1 wrote 24 bytes "fd 6 is done and failed " 57506 dillo RET write 24/0x18 57506 dillo CALL close(6) 57506 dillo RET close 0 57506 dillo CALL getpid() 57506 dillo RET getpid 57506/0xe0a2 57506 dillo CALL write(2,0x759b98291bf0,0x18) 57506 dillo GIO fd 2 wrote 24 bytes "dillo(57506) in free(): " 57506 dillo RET write 24/0x18 57506 dillo CALL write(2,0x759b98291cd0,0x29) 57506 dillo GIO fd 2 wrote 41 bytes "write to free mem 0xc48c3dbd80[24..31]@32" 57506 dillo RET write 41/0x29 57506 dillo CALL write(2,0x759b98291bf0,0x1) 57506 dillo GIO fd 2 wrote 1 bytes " " 57506 dillo RET write 1 57506 dillo CALL sigprocmask(SIG_SETMASK,~0x20<SIGABRT>) 57506 dillo RET sigprocmask 0<> 57506 dillo CALL thrkill(0,SIGABRT,0) 57506 dillo PSIG SIGABRT SIG_DFL 57506 dillo NAMI "dillo.core"
Hi, On Wed, Aug 28, 2024 at 08:14:20PM +0200, a1ex@dismail.de wrote:
Hi,
On Wed, 28 Aug 2024 19:12:43 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
You may be able to get some info on where it is failing by building Dillo with the address sanitizer enabled:
$ git clone https://github.com/dillo-browser/dillo $ cd dillo $ ./autogen.sh $ mkdir build $ cd build $ ../configure 'CFLAGS=-Og -g -fsanitize=address' 'CXXFLAGS=-Og -g -fsanitize=address' $ make $ src/dillo https://narkive.com
That doesn't seem to work:
$ ../configure 'CFLAGS=-Og -g -fsanitize=address' 'CXXFLAGS=-Og -g -fsanitize=address' checking build system type... x86_64-unknown-openbsd7.6 [...] configure: error: C compiler cannot create executables See `config.log' for more details
Oh, I didn't knew it was not supported in OpenBSD. Well, I added a simple patch to reproduce your problem, and I got a heap use after free with asan: hop% LD_LIBRARY_PATH=/usr/lib/libressl src/dillo https://narkive.com dillo_dns_init: Here we go! (threaded) TLS library: LibreSSL 3.9.2 Enabling cookies as from cookiesrc... Nav_open_url: new url='https://narkive.com' Dns_server [0]: narkive.com is 149.248.211.108 Connecting to 149.248.211.108:443 TLS connect error: "an EOF was observed that violates the protocol" Tls_close_by_key: Avoiding SSL shutdown for: https://narkive.com fd 6 is done and failed ================================================================= ==1646866==ERROR: AddressSanitizer: heap-use-after-free on address 0x5030002c8649 at pc 0x64733a019b37 bp 0x7ffd6d8bfe00 sp 0x7ffd6d8bfdf0 WRITE of size 1 at 0x5030002c8649 thread T0 #0 0x64733a019b36 in Tls_connect IO/../../../src/IO/tls_openssl.c:1201 #1 0x64733a019d88 in a_Tls_openssl_connect IO/../../../src/IO/tls_openssl.c:1266 #2 0x64733a019e9a in a_Tls_connect IO/../../../src/IO/tls.c:133 #3 0x64733a01a10d in Http_connect_tls IO/../../../src/IO/http.c:521 #4 0x64733a01b7c4 in Http_connect_socket_cb IO/../../../src/IO/http.c:555 #5 0x769620b7c1f3 in fl_wait(double) (/usr/lib/libfltk.so.1.3+0xa51f3) (BuildId: 80ecc607ef6caa03d5591ba84ff58945ff1be889) #6 0x769620b1b09a in Fl::wait(double) (/usr/lib/libfltk.so.1.3+0x4409a) (BuildId: 80ecc607ef6caa03d5591ba84ff58945ff1be889) #7 0x769620b1b15d in Fl::run() (/usr/lib/libfltk.so.1.3+0x4415d) (BuildId: 80ecc607ef6caa03d5591ba84ff58945ff1be889) #8 0x647339fd912c in main ../../src/dillo.cc:583 #9 0x769620039c87 (/usr/lib/libc.so.6+0x25c87) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) #10 0x769620039d4b in __libc_start_main (/usr/lib/libc.so.6+0x25d4b) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) #11 0x647339fb8894 in _start (/home/ram/dev/dillo/git/build-libressl/src/dillo+0xe1894) (BuildId: 83bcb2b57d527264c53219ed2204e01b019e3e34) 0x5030002c8649 is located 25 bytes inside of 32-byte region [0x5030002c8630,0x5030002c8650) freed by thread T0 here: #0 0x769620cfb422 in free /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:52 #1 0x64733a083ca3 in dFree ../../dlib/dlib.c:70 #2 0x64733a019782 in Tls_connect IO/../../../src/IO/tls_openssl.c:1192 #3 0x64733a019d88 in a_Tls_openssl_connect IO/../../../src/IO/tls_openssl.c:1266 #4 0x64733a019e9a in a_Tls_connect IO/../../../src/IO/tls.c:133 #5 0x64733a01a10d in Http_connect_tls IO/../../../src/IO/http.c:521 #6 0x64733a01b7c4 in Http_connect_socket_cb IO/../../../src/IO/http.c:555 #7 0x769620b7c1f3 in fl_wait(double) (/usr/lib/libfltk.so.1.3+0xa51f3) (BuildId: 80ecc607ef6caa03d5591ba84ff58945ff1be889) #8 0x769620b1b09a in Fl::wait(double) (/usr/lib/libfltk.so.1.3+0x4409a) (BuildId: 80ecc607ef6caa03d5591ba84ff58945ff1be889) #9 0x769620b1b15d in Fl::run() (/usr/lib/libfltk.so.1.3+0x4415d) (BuildId: 80ecc607ef6caa03d5591ba84ff58945ff1be889) #10 0x647339fd912c in main ../../src/dillo.cc:583 #11 0x769620039c87 (/usr/lib/libc.so.6+0x25c87) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) #12 0x769620039d4b in __libc_start_main (/usr/lib/libc.so.6+0x25d4b) (BuildId: 32a656aa5562eece8c59a585f5eacd6cf5e2307b) #13 0x647339fb8894 in _start (/home/ram/dev/dillo/git/build-libressl/src/dillo+0xe1894) (BuildId: 83bcb2b57d527264c53219ed2204e01b019e3e34) previously allocated by thread T0 here: #0 0x769620cfca31 in malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x64733a083c3a in dMalloc ../../dlib/dlib.c:47 SUMMARY: AddressSanitizer: heap-use-after-free IO/../../../src/IO/tls_openssl.c:1201 in Tls_connect Shadow bytes around the buggy address: 0x5030002c8380: fa fa fd fd fd fa fa fa fd fd fd fd fa fa fd fd 0x5030002c8400: fd fd fa fa 00 00 00 00 fa fa fd fd fd fd fa fa 0x5030002c8480: fd fd fd fd fa fa fd fd fd fd fa fa fd fd fd fd 0x5030002c8500: fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 0x5030002c8580: 00 fa fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa =>0x5030002c8600: 00 00 00 fa fa fa fd fd fd[fd]fa fa fd fd fd fa 0x5030002c8680: fa fa fd fd fd fa fa fa 00 00 00 fa fa fa 00 00 0x5030002c8700: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 fa fa fa 0x5030002c8780: fd fd fd fd fa fa fd fd fd fd fa fa fd fd fd fd 0x5030002c8800: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd 0x5030002c8880: fd fd fa fa fd fd fd fd fa fa fd fd fd fd fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==1646866==ABORTING Hopefully is the same you are seeing. Here is the patch I'm using: diff --git a/src/IO/tls_openssl.c b/src/IO/tls_openssl.c index 3e68e928..05d795a5 100644 --- a/src/IO/tls_openssl.c +++ b/src/IO/tls_openssl.c @@ -1108,8 +1108,11 @@ static void Tls_connect(int fd, int connkey) a_IOwatch_remove_fd(fd, -1); + ret = 0; + if (ret <= 0) { int err1_ret = SSL_get_error(conn->ssl, ret); + err1_ret = SSL_ERROR_SYSCALL; if (err1_ret == SSL_ERROR_WANT_READ || err1_ret == SSL_ERROR_WANT_WRITE) { int want = err1_ret == SSL_ERROR_WANT_READ ? DIO_READ : DIO_WRITE; This is enough for me to at least fix this case on Dillo side. However, it doesn't explain the EOF you are getting in narkive. Are you using tor or some proxy? Best, Rodrigo.
Hi,
This is enough for me to at least fix this case on Dillo side.
I see, I was trying to set the conn->in_connect = FALSE after conn was freed. Try this patch: diff --git a/src/IO/tls_openssl.c b/src/IO/tls_openssl.c index 3e68e928..5ad12b8c 100644 --- a/src/IO/tls_openssl.c +++ b/src/IO/tls_openssl.c @@ -1186,7 +1186,10 @@ static void Tls_connect(int fd, int connkey) if (a_Klist_get_data(conn_list, connkey)) { conn->connecting = FALSE; if (failed) { + conn->in_connect = FALSE; Tls_close_by_key(connkey); + /* conn is freed now */ + conn = NULL; } a_IOwatch_remove_fd(fd, DIO_READ|DIO_WRITE); a_Http_connect_done(fd, failed ? FALSE : TRUE); @@ -1195,7 +1198,8 @@ static void Tls_connect(int fd, int connkey) } } - conn->in_connect = FALSE; + if (conn) + conn->in_connect = FALSE; } static void Tls_connect_cb(int fd, void *vconnkey)
On Wed, 28 Aug 2024 21:40:20 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
Hi,
This is enough for me to at least fix this case on Dillo side.
I see, I was trying to set the conn->in_connect = FALSE after conn was freed. Try this patch:
diff --git a/src/IO/tls_openssl.c b/src/IO/tls_openssl.c index 3e68e928..5ad12b8c 100644 --- a/src/IO/tls_openssl.c +++ b/src/IO/tls_openssl.c @@ -1186,7 +1186,10 @@ static void Tls_connect(int fd, int connkey) if (a_Klist_get_data(conn_list, connkey)) { conn->connecting = FALSE; if (failed) { + conn->in_connect = FALSE; Tls_close_by_key(connkey); + /* conn is freed now */ + conn = NULL; } a_IOwatch_remove_fd(fd, DIO_READ|DIO_WRITE); a_Http_connect_done(fd, failed ? FALSE : TRUE); @@ -1195,7 +1198,8 @@ static void Tls_connect(int fd, int connkey) } }
- conn->in_connect = FALSE; + if (conn) + conn->in_connect = FALSE; }
static void Tls_connect_cb(int fd, void *vconnkey)
I have confirmed that this patch prevents Dillo from crashing. Thanks!
However, it doesn't explain the EOF you are getting in narkive. Are you using tor or some proxy?
No vpn/tor/proxy. I wouldn't be surprised if my network provider was doing some weird stuff though... Maybe thats an area for further study. -Alex
Thanks to both of you for tracking this down. I pulled the fix into the OpenBSD port for now.
Hi,
I have confirmed that this patch prevents Dillo from crashing. Thanks!
Nice!
However, it doesn't explain the EOF you are getting in narkive. Are you using tor or some proxy?
No vpn/tor/proxy. I wouldn't be surprised if my network provider was doing some weird stuff though... Maybe thats an area for further study.
Look at what I just found: hop% torsocks curl -v https://narkive.com * Host narkive.com:443 was resolved. * IPv6: (none) * IPv4: 149.248.211.108 * Trying 149.248.211.108:443... * Connected to narkive.com (149.248.211.108) port 443 * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: none * OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to narkive.com:443 * Closing connection curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to narkive.com:443 Same if I pass Dillo traffic via tor. I think your IP may be banned from narkive. Try in some days or reset your router if you have a dynamic IP. Or mail them if persists. Best, Rodrigo.
Hi Rodrigo, On Wed, 28 Aug 2024 23:02:38 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
I think your IP may be banned from narkive.
Yeah, that does sound like it could be the case. Funny, because I've never even used that site before. I have a static IP address, so that might have something to do with it. On the plus side, without this issue we wouldn't have found the crash in Dillo, so, thank you narkive for inadvertently helping Dillo :) Regards, Alex
Hi Alex, On Thu, Aug 29, 2024 at 12:04:12PM +0200, a1ex@dismail.de wrote:
Hi Rodrigo,
On Wed, 28 Aug 2024 23:02:38 +0200 Rodrigo Arias <rodarima@gmail.com> wrote:
I think your IP may be banned from narkive.
Yeah, that does sound like it could be the case. Funny, because I've never even used that site before. I have a static IP address, so that might have something to do with it.
I'm thinking if you ever ran an exit Tor node that could be a plausible explanation.
On the plus side, without this issue we wouldn't have found the crash in Dillo, so, thank you narkive for inadvertently helping Dillo :)
Yes, this is more a symptom that we don't have enough tests. I'm thinking how to improve the test infrastructure so we can include more complex tests like bad TLS responses from a https server, among others. Best, Rodrigo.
participants (3)
-
a1ex＠dismail.de -
Rodrigo Arias -
Theo Buehler