Dillo-dev

Download

By thread

dillo-dev@mailman3.com

1 participants
11683 messages

Avoid ctype(3) abuses

by Leonardo Taccari

Hello! Most ctype(3) functions usage abuses an undefined behavior of passing values outside integers outside EOF or the range representable as unsigned char. On NetBSD 11 and newer such incorrect behaviors crashes applications violating that and due that Dillo easily crash by just visiting, e.g. <https://www.NetBSD.org/>. For possible further information please give a look to <https://man.NetBSD.org/ctype.3#CAVEATS>. I have grep-ed all such uses and added the relevant cast to uchar_t similar to other ctype(3) calls already present and in that way I can also confirm that Dillo no longer crashes. Attached in this email you can find a patch to address that. Thank you!

Jan. 12, 2026

Include missing <stdlib.h> for calloc(3) and exit(3)

by Leonardo Taccari

Hello! When trying to build current HEAD of dillo in NetBSD the build fails with: [...] g++ ... -o dialog.o dialog.cc [...] dialog.cc:38:1: note: 'calloc' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' 37 | #include "dlib/dlib.h" +++ |+#include <cstdlib> 38 | dialog.cc:192:11: error: 'exit' was not declared in this scope 192 | exit(1); | ^~~~ dialog.cc:192:11: note: 'exit' is defined in header '<cstdlib>'; this is probably fixable by adding '#include <cstdlib>' *** [dialog.o] Error code 1 [...] Including <stdlib.h> fixes that and the attached patch does that. Thank you!

Jan. 12, 2026

Re: Remote control socket (experimental)

by a1ex＠dismail.de

Rodrigo Arias <rodarima(a)gmail.com> wrote: > I took a closer look and it seems that this patch doesn't address the > actual problem. The problem is that BSD inherits the non-blocking > behavior while Linux doesn't (POSIX doesn't seem to indicate what should > be done). We want the new_fd to work in blocking mode, so this patch > should fix it for BSD and Linux (otherwise let me know): > > ---8<--- > diff --git a/src/IO/control.c b/src/IO/control.c > index 6f677e52..0d11187e 100644 > --- a/src/IO/control.c > +++ b/src/IO/control.c > @@ -95,12 +95,30 @@ static void Control_read_cb(int fd, void *data) > > int new_fd = accept(control_fd, NULL, NULL); > if (new_fd < 0) { > - if (errno != EWOULDBLOCK) { > - MSG("accept failed: %s\n", strerror(errno)); > + if (errno == EAGAIN || errno == EWOULDBLOCK) { > + /* Nothing? */ > + return; > + } else { > + MSG_ERR("accept failed: %s\n", strerror(errno)); > exit(1); > } > - /* Nothing? */ > - return; > + } > + > + /* From accept(2) man page: > + * > + * On Linux, the new socket returned by accept() does not inherit > + * file status flags such as O_NONBLOCK and O_ASYNC from the > + * listening socket. This behavior differs from the canonical BSD > + * sockets implementation. Portable programs should not rely on > + * inheritance or noninheritance of file status flags and always > + * explicitly set all required flags on the socket returned from > + * accept(). > + * > + * So, disable O_NONBLOCK flag explicitly. > + */ > + if (fcntl(new_fd, F_SETFL, 0) == -1) { > + MSG_ERR("control socket fcntl failed: %s\n", strerror(errno)); > + exit(1); > } > > ssize_t r; > ---8<--- Tested & works fine here :)

Dec. 20, 2025

Re: Remote control socket (experimental)

by a1ex＠dismail.de

Hi, Rodrigo Arias <rodarima(a)gmail.com> wrote: > > PS. Any chance of adding an option to reload dillorc prefs too? :) > > That would be doable, but I'm not sure if we can just re-parse all > settings as-is without propagating the new values to other parts of > Dillo which might have made a copy. > > Which use case do you have in mind? For the user agent rotation? That was my initial use-case, but I also think that being able to change things like fonts and colors without having to restart dillo could be more useful for average users. For example switching between a light and dark color mode, or switching between regular fonts and CJK, etc. Thanks! Alex

Dec. 20, 2025

Re: Remote control socket (experimental)

by Rodrigo Arias

Hi, > Tested & works fine here :) Thanks for testing, I merged it. Best, Rodrigo.

Dec. 20, 2025

Re: Remote control socket (experimental)

by a1ex＠dismail.de

Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > > Right away dillo exits and the console message shows this: > > > > ** ERROR **: Control_read_cb Resource temporarily unavailable > > Hmm, I don't think I'm catching all possible errors from that socket. > Maybe this patch can help: > > ---8<--- > diff --git a/src/IO/control.c b/src/IO/control.c > index 6f677e52..c6cd15bf 100644 > --- a/src/IO/control.c > +++ b/src/IO/control.c > @@ -110,7 +110,7 @@ static void Control_read_cb(int fd, void *data) > r = read(new_fd, buf, 1); > _MSG("read = %zd\n", r); > if (r < 0) { > - if (errno == EINTR) { > + if (errno == EINTR || errno == EAGAIN || errno == EWOULDBLOCK) { > continue; > } else { > MSG_ERR("Control_read_cb %s\n", dStrerror(errno)); > ---8<--- > > Let me know if that makes it work. Looks to be working now! Thanks for this very cool new feature, BTW! Regards, Alex PS. Any chance of adding an option to reload dillorc prefs too? :)

Dec. 20, 2025

Re: Remote control socket (experimental)

by Rodrigo Arias

Hi, On Sat, Dec 20, 2025 at 01:24:55PM +0000, a1ex(a)dismail.de wrote: > > Hmm, I don't think I'm catching all possible errors from that > > socket. Maybe this patch can help: > > > > ---8<--- > > diff --git a/src/IO/control.c b/src/IO/control.c > > index 6f677e52..c6cd15bf 100644 > > --- a/src/IO/control.c > > +++ b/src/IO/control.c > > @@ -110,7 +110,7 @@ static void Control_read_cb(int fd, void *data) > > r = read(new_fd, buf, 1); > > _MSG("read = %zd\n", r); > > if (r < 0) { > > - if (errno == EINTR) { > > + if (errno == EINTR || errno == EAGAIN || errno == EWOULDBLOCK) { > > continue; > > } else { > > MSG_ERR("Control_read_cb %s\n", dStrerror(errno)); > > ---8<--- > > > > Let me know if that makes it work. > > Looks to be working now! Thanks for this very cool new feature, BTW! I took a closer look and it seems that this patch doesn't address the actual problem. The problem is that BSD inherits the non-blocking behavior while Linux doesn't (POSIX doesn't seem to indicate what should be done). We want the new_fd to work in blocking mode, so this patch should fix it for BSD and Linux (otherwise let me know): ---8<--- diff --git a/src/IO/control.c b/src/IO/control.c index 6f677e52..0d11187e 100644 --- a/src/IO/control.c +++ b/src/IO/control.c @@ -95,12 +95,30 @@ static void Control_read_cb(int fd, void *data) int new_fd = accept(control_fd, NULL, NULL); if (new_fd < 0) { - if (errno != EWOULDBLOCK) { - MSG("accept failed: %s\n", strerror(errno)); + if (errno == EAGAIN || errno == EWOULDBLOCK) { + /* Nothing? */ + return; + } else { + MSG_ERR("accept failed: %s\n", strerror(errno)); exit(1); } - /* Nothing? */ - return; + } + + /* From accept(2) man page: + * + * On Linux, the new socket returned by accept() does not inherit + * file status flags such as O_NONBLOCK and O_ASYNC from the + * listening socket. This behavior differs from the canonical BSD + * sockets implementation. Portable programs should not rely on + * inheritance or noninheritance of file status flags and always + * explicitly set all required flags on the socket returned from + * accept(). + * + * So, disable O_NONBLOCK flag explicitly. + */ + if (fcntl(new_fd, F_SETFL, 0) == -1) { + MSG_ERR("control socket fcntl failed: %s\n", strerror(errno)); + exit(1); } ssize_t r; ---8<--- Best, Rodrigo.

Dec. 20, 2025

Re: Remote control socket (experimental)

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > I have just merged the support to control dillo from a UNIX control > socket. There is now a new program called "dilloc" to send commands > from the CLI. If there is only one dillo process it will choose it, > otherwise it needs to be specified in the DILLO_PID env var. I just went to test this and ran into a possible issue. This is with a fully stock dillo build/install, running on OpenBSD 7.8 amd64: $ dillo -v Dillo Libraries: fltk/1.3.9 jpeg/3.1.2 png/1.6.50 webp/1.6.0 zlib/1.3.1.1-motley brotli/1.0.9 LibreSSL/4.2.0 Features: +GIF +JPEG +PNG +SVG +WEBP +BROTLI +XEMBED +TLS +IPV6 +CTL $ dillo paths: Creating directory '/home/user/.dillo/' paths: Cannot open file '/home/user/.dillo/dillorc': No such file or directory paths: Using /usr/local/etc/dillo/dillorc paths: Cannot open file '/home/user/.dillo/keysrc': No such file or directory paths: Using /usr/local/etc/dillo/keysrc paths: Cannot open file '/home/user/.dillo/domainrc': No such file or directory paths: Using /usr/local/etc/dillo/domainrc Domain: Default accept. dillo_dns_init: Here we go! (threaded) TLS library: LibreSSL 4.2.0 Cookies: Created file: /home/user/.dillo/cookiesrc Disabling cookies. paths: Cannot open file '/home/user/.dillo/hsts_preload': No such file or directory paths: Using /usr/local/etc/dillo/hsts_preload Nav_open_url: new url='about:splash' Dillo starts normally, then I do this: $ dilloc help Right away dillo exits and the console message shows this: ** ERROR **: Control_read_cb Resource temporarily unavailable This is with just one dillo process running, but I also tested with setting the DILLO_PID variable. That actually gives a working result for only one try, and then gives the error if you try again: $ dillo & [1] 12345 ... $ export DILLO_PID=12345 $ dilloc ping pong $ dilloc ping ** ERROR **: Control_read_cb Resource temporarily unavailable (dillo exits) I verified that the process ID remains unchanged and the variable is still set between dilloc runs, so I'm not sure what's going on. Happy to troubleshoot further if you have any suggestions. Regards, Alex

Dec. 20, 2025

Re: Remote control socket (experimental)

by Bobby Hiltz

That is exactly what happened. I didn't run dillo, I tried running `dilloc help` first. Like many errors, this one was between the keyboard and the chair.

Dec. 20, 2025

Re: Remote control socket (experimental)

by Rodrigo Arias

Hi, > Looks to be working now! Thanks for this very cool new feature, BTW! Nice! Let me know if you find some other problems. > PS. Any chance of adding an option to reload dillorc prefs too? :) That would be doable, but I'm not sure if we can just re-parse all settings as-is without propagating the new values to other parts of Dillo which might have made a copy. Which use case do you have in mind? For the user agent rotation? Best, Rodrigo.

Dec. 20, 2025

Jump to page: