- Dillo-dev - lists.mailman3.com

Re: Scrollbar themeing

by Rodrigo Arias

Hi, On Sun, Oct 13, 2024 at 05:56:26PM +0200, a1ex(a)dismail.de wrote: >Hi, > >When using a dark theme, the scrollbar can be very hard to see: > >https://alex.envs.net/test/scroll-theme-stock1.png > >I made some changes and now the scrollbar looks nicer and is more >visible: > >https://alex.envs.net/test/scroll-theme-mod1.png > >If someone wants to try it, here is a patch which also includes some >commented lines which you can use to further customize the appearance >of the scrollbar. I think this is a side effect of altering the colormap only partially. I would imagine that by mapping *all* light colors to dark counterparts, you will get coherent box borders. Here is more info: https://www.fltk.org/doc-1.3/drawing.html https://www.fltk.org/doc-1.3/drawing.html#drawing_colors This is an example of such colormap that may be easy to try using Fl:set_color(): https://github.com/fltk-rs/fltk-theme/blob/main/src/color_themes/dark.rs https://www.fltk.org/doc-1.3/group__fl__attributes.html#gac62f634ba8089a9d0… Best, Rodrigo.

Oct. 13, 2024

Re: Navigation by pages

by Rodrigo Arias

>Nice, this will probably become my default setting now. > >Thanks for this awesome patch! Thanks! Here are a couple of improvements: https://github.com/dillo-browser/dillo/pull/278 Clicking on the scrollbar arrows jumps to the top or bottom, and holding the button pressed will repeat the page scrolling. This only happens when the page scrolling mode is enabled (x)or Shift is hold. Please check the repeat and delay speeds, as I would rather prefer not to add more options to dillorc today :-) Also, do you usually set focus_new_tab to NO?, I'm considering switching the default to NO. Same with show_quit_dialog. Best, Rodrigo.

Oct. 13, 2024

Re: scroll_step description

by Rodrigo Arias

Hi, On Sat, Apr 20, 2024 at 01:54:26PM +1000, Kevin Koster wrote: >There's a new "scroll_step" option in the example configuration file for >3.1.0-rc1. The comment "Mouse wheel scroll step in pixels" suggests that >this only affects the mouse wheel, but it also changes the distance the >page moves when the arrow keys are pressed and the overlap of >previous page content that's left when you press Page Up/Down. I think >that's a little confusing, especially as the value has changed since >the default behaviour in 3.0.5 (the old value seems to have been about >25). This is now controlled independently with the scroll_page_overlap, which by default uses the value 50 px. While the scroll_step controls how much it advances with the arrows, by default 100 pixels. See: https://github.com/dillo-browser/dillo/pull/277 Best, Rodrigo.

Oct. 13, 2024

Scrollbar themeing

by a1ex＠dismail.de

Hi, When using a dark theme, the scrollbar can be very hard to see: https://alex.envs.net/test/scroll-theme-stock1.png I made some changes and now the scrollbar looks nicer and is more visible: https://alex.envs.net/test/scroll-theme-mod1.png If someone wants to try it, here is a patch which also includes some commented lines which you can use to further customize the appearance of the scrollbar. -Alex --- a/dw/fltkviewport.cc Sat Oct 12 22:05:30 2024 +++ b/dw/fltkviewport.cc Sun Oct 13 16:23:06 2024 @@ -59,12 +59,20 @@ FltkViewport::FltkViewport (int X, int Y, int W, int H hscrollbar = new CustScrollbar (x (), y (), 1, 1); hscrollbar->type(FL_HORIZONTAL); + // Horizontal scrollbar theme options: + // hscrollbar->color(FL_BLUE, FL_YELLOW); + // hscrollbar->box(FL_ENGRAVED_BOX); + hscrollbar->slider(FL_PLASTIC_DOWN_BOX); hscrollbar->callback (hscrollbarCallback, this); hscrollbar->hide(); add (hscrollbar); vscrollbar = new Fl_Scrollbar (x (), y(), 1, 1); vscrollbar->type(FL_VERTICAL); + // Vertical scrollbar theme options: + // vscrollbar->color(FL_BLUE, FL_YELLOW); + // vscrollbar->box(FL_ENGRAVED_BOX); + vscrollbar->slider(FL_PLASTIC_DOWN_BOX); vscrollbar->callback (vscrollbarCallback, this); vscrollbar->hide(); add (vscrollbar);

Oct. 13, 2024

Re: Navigation by pages

by a1ex＠dismail.de

Hi, > First, you can now scroll the mouse wheel over the vertical scrollbar > to jump whole pages instead of small steps. Over the page it > continues to behave as normal, unless you hold Shift, which will also > make it navigate full pages. This works really great, thanks! > Secondly, I also added a scrollbar "page mode", which can be enabled > in dillorc with scrollbar_page_mode=YES, which causes clicking with > the left button *anywhere* on the vertical scrollbar (including the > thumb) to scroll one page down. With the right button, one up. > Holding Shift can also enable temporarily this mode (or disable it). Another good feature, very useful if using a laptop or mouse without a proper scrollwheel. > I also added an option to place the vertical scrollbar on the left, > which I'm finding more convenient as it is usually closer to the text. Nice, this will probably become my default setting now. Thanks for this awesome patch! -Alex

Oct. 12, 2024

Re: Navigation by pages

by Rodrigo Arias

Hi, >Now having tried both, I feel that the button is still a bit nicer from >a usability standpoint, because it requires less attention and mouse >movement to go up and down. But, I agree there is not much point in >duplicating this functionality. I added a couple of options to improve the page navigation. First, you can now scroll the mouse wheel over the vertical scrollbar to jump whole pages instead of small steps. Over the page it continues to behave as normal, unless you hold Shift, which will also make it navigate full pages. Secondly, I also added a scrollbar "page mode", which can be enabled in dillorc with scrollbar_page_mode=YES, which causes clicking with the left button *anywhere* on the vertical scrollbar (including the thumb) to scroll one page down. With the right button, one up. Holding Shift can also enable temporarily this mode (or disable it). I also added an option to place the vertical scrollbar on the left, which I'm finding more convenient as it is usually closer to the text. Here is the PR that includes all the above, not merged yet: https://github.com/dillo-browser/dillo/pull/274 Best, Rodrigo.

Oct. 12, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > Place a breakpoint here: > > https://github.com/dillo-browser/dillo/blob/master/src/IO/IO.c#L189 > > Likely with "b IO.c:189", then "c" and "bt". > > That backtrace along with the stderr lines: > > >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 > >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 > > Can tell what is the state of the CCC at the moment that error > happens. > > The backtrace you attach happens later, so we already miss the point > where the problem occurs. I built and installed a clean Dillo with your file dpi patch. Here is that backtrace, which is from right before this: "WRITE Failed with -1: Broken pipe" [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 a_IO_ccc : OpSend [2F] Info=0xb5c0c2eba40 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xb5c0c30d000 Flags=0 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 a_Capi_ccc : OpSend [2F] Info=0xb5c0c30de00 Flags=0 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48be80, flags=5 state=12 a_IO_ccc : OpSend [2F] Info=0xb5c0c2eba40 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xb5c0c30d000 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xb5c0c30de00 Flags=0 a_IO_ccc : OpEnd [2F] Info=0xb5c0c2eba40 Flags=0 a_Dpi_ccc : OpEnd [2F] Info=0xb5c0c30d000 Flags=0 a_Capi_ccc : OpEnd [2F] Info=0xb5c0c30de00 Flags=0 HTTP warning: Content-Length (937694) does NOT match message body (921310) for file:/tmp/dillo-doublefree.html a_Capi_ccc : OpEnd [1B] Info=0xb5c0c30d3c0 Flags=0 a_Dpi_ccc : OpEnd [1B] Info=0xb5c0c30d0c0 Flags=0 a_IO_ccc : OpEnd [1B] Info=0xb5c4883b140 Flags=0 Program received signal SIGPIPE, Broken pipe. _thread_sys_write () at /tmp/-:2 2 /tmp/-: No such file or directory. (gdb) bt #0 _thread_sys_write () at /tmp/-:2 #1 0x0ea252bb530f97da in ?? () #2 0x00000b5c41b50c52 in _libc_write_cancel (fd=7, buf=0xb5be6ed0000, nbytes=72966) at /usr/src/lib/libc/sys/w_write.c:27 #3 0x00000b597324b065 in IO_write (io=0xb5c48870ba0) at IO.c:230 #4 IO_callback (io=0xb5c48870ba0) at IO.c:275 #5 0x00000b597324adc9 in IO_fd_write_cb (fd=7, data=<optimized out>) at IO.c:317 #6 0x00000b5c1e858e88 in fl_wait(double) () from /usr/local/lib/libfltk.so.8.0 #7 0x00000b5c1e7e8a6e in Fl::wait(double) () from /usr/local/lib/libfltk.so.8.0 #8 0x00000b5c1e7e8c4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 #9 0x00000b59731f23b5 in main () (gdb) c Continuing. WRITE Failed with -1: Broken pipe a_IO_ccc : OpAbort [1F] Info=0xb5c4886d440 Flags=0 a_Dpi_ccc : OpAbort [1F] Info=0xb5c4886d180 Flags=0 a_Capi_ccc : OpAbort [1F] Info=0xb5c4883ba00 Flags=0 Here is another: a_Capi_ccc : OpStart [2B] Info=0xb5c0c2eba80 Flags=0 a_Dpi_ccc : OpStart [2B] Info=0xb5c48368640 Flags=0 a_IO_ccc : OpStart [2B] Info=0xb5c4886d400 Flags=0 a_Capi_ccc : OpStart [1B] Info=0xb5c4883b0c0 Flags=0 a_Dpi_ccc : OpStart [1B] Info=0xb5bc9415100 Flags=0 a_IO_ccc : OpStart [1B] Info=0xb5c483686c0 Flags=0 a_IO_ccc : OpSend [1B] Info=0xb5c483686c0 Flags=0 a_Capi_ccc : OpSend [1F] Info=0xb5c4883b0c0 Flags=0 a_Capi_ccc : OpSend [2B] Info=0xb5c0c2eba80 Flags=0 a_Dpi_ccc : OpSend [2B] Info=0xb5c48368640 Flags=0 a_IO_ccc : OpSend [2B] Info=0xb5c4886d400 Flags=0 a_Capi_ccc : OpSend [1F] Info=0xb5c4883b0c0 Flags=0 a_Capi_ccc : OpSend [1B] Info=0xb5c4883b0c0 Flags=0 a_Dpi_ccc : OpSend [1B] Info=0xb5bc9415100 Flags=0 a_IO_ccc : OpSend [1B] Info=0xb5c483686c0 Flags=0 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 a_IO_ccc : OpSend [2F] Info=0xb5c4886d940 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xb5c4886d9c0 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xb5c0c30d980 Flags=0 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 a_IO_ccc : OpSend [2F] Info=0xb5c4886d940 Flags=0 a_Dpi_ccc : OpSend [2F] Info=0xb5c4886d9c0 Flags=0 a_Capi_ccc : OpSend [2F] Info=0xb5c0c30d980 Flags=0 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 Breakpoint 1, IO_read (io=0xb5c08fc3640) at IO.c:189 189 MSG("READ Failed with %d: %s\n", (int)St, strerror(errno)); (gdb) [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 bt #0 IO_read (io=0xb5c08fc3640) at IO.c:189 #1 IO_callback (io=0xb5c08fc3640) at IO.c:273 #2 0x00000b597324acc9 in IO_fd_read_cb (fd=7, data=0x51) at IO.c:294 #3 0x00000b5c1e858e88 in fl_wait(double) () from /usr/local/lib/libfltk.so.8.0 #4 0x00000b5c1e7e8a6e in Fl::wait(double) () from /usr/local/lib/libfltk.so.8.0 #5 0x00000b5c1e7e8c4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 #6 0x00000b59731f23b5 in main () (gdb) [file dpi]: File_serve_client 0x4b2ed48eb80, flags=5 state=12 (gdb) c Continuing. READ Failed with -1: Connection reset by peer a_IO_ccc : OpAbort [2F] Info=0xb5c4886d180 Flags=0 a_Dpi_ccc : OpAbort [2F] Info=0xb5c0c2eb880 Flags=0 ** WARNING **: Unused CCC Program received signal SIGPIPE, Broken pipe. _thread_sys_write () at /tmp/-:2 2 /tmp/-: No such file or directory. > This line: > > > READ Failed with -1: Connection reset by peer > > Is complaining that either a read() call or a Tls_read() failed. I > will assume it is the read() as there shouldn't be any https traffic > in your local test. It is communicating with the file DPI via a > socket. Thats interesting, in my previous testing a few days ago I noticed some messages about 'a_Tls_connection' in the debugger, which made no sense since I'm working with a local file: (gdb) break IO_write Breakpoint 1 at 0x9c0c8fc2fff: file IO.c, line 223. (gdb) c Continuing. WRITE Failed with -1: Broken pipe a_IO_ccc : OpAbort [1F] Info=0x9c335b28580 Flags=0 a_Dpi_ccc : OpAbort [1F] Info=0x9c335b00c40 Flags=0 a_Capi_ccc : OpAbort [1F] Info=0x9c335b00c00 Flags=0 Breakpoint 1, IO_write (io=0x9c38396eb40) at IO.c:223 223 void *conn = a_Tls_connection(io->FD); Regards, Alex

Oct. 12, 2024

Re: Rendering issue with view source and large embedded images

by Rodrigo Arias

Hi, >I managed to get the newer FLTK working and built Dillo with it, but >unfortunately it doesn't fix the view-source glitch or the image >rendering problem. I assume that could happen if the CCC is broken while transferring the images, then the decoder starts to hallucinate colors. Valgrind may be able to detect where the corruption begins. >I'm not exactly sure how to set the breakpoint for that specific event, >but I managed to get a more detailed backtrace which might be useful >(see attached). Place a breakpoint here: https://github.com/dillo-browser/dillo/blob/master/src/IO/IO.c#L189 Likely with "b IO.c:189", then "c" and "bt". That backtrace along with the stderr lines: >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 Can tell what is the state of the CCC at the moment that error happens. The backtrace you attach happens later, so we already miss the point where the problem occurs. This line: > READ Failed with -1: Connection reset by peer Is complaining that either a read() call or a Tls_read() failed. I will assume it is the read() as there shouldn't be any https traffic in your local test. It is communicating with the file DPI via a socket. However, in your log it seems that it is opening three CCC links: a_IO_ccc : OpStart [1B] Info=0xebe57007340 Flags=0 a_IO_ccc : OpStart [2B] Info=0xebeef295240 Flags=0 a_IO_ccc : OpStart [2B] Info=0xebeef2be980 Flags=0 a_IO_ccc : OpStart [1B] Info=0xebee90ace40 Flags=0 a_IO_ccc : OpStart [2B] Info=0xebe57007e40 Flags=0 a_IO_ccc : OpStart [1B] Info=0xebe57007100 Flags=0 The 1B and 2B is explained in devdoc/CCCwork.txt: Query: | . 1B --> 1B 1B --> 1B --> | -------------. .----. .----. .----. . | I |Capi| |http| | IO | | | '----' '----' '----' . | 1F <-- 1F 1F <-- 1F | V . | [Server] Answer: . 2B --> 2B 2B --> 2B | | .----. .----. .----. . | II |Capi| |Dpi | | IO | | | '----' '----' '----' . | 2F <-- 2F 2F <-- 2F <-- | <------------' ^ . fails here | But in my cases, I'm not able to have multiple CCC started before the previous one aborts, even if I reload all the time. If that is the case, then maybe even Valgrind won't be able to show you where the problem starts. This will probably require some "properly placed printf() calls" debugging. You may use this patch to enable some verbose messages on the file DPI to gather more info: diff --git a/dpi/file.c b/dpi/file.c index ecee90ea..1b67fab7 100644 --- a/dpi/file.c +++ b/dpi/file.c @@ -936,8 +936,8 @@ static void File_serve_client(void *data, int f_write) int st; while (1) { - _MSG("File_serve_client %p, flags=%d state=%d\n", - client, client->flags, client->state); + MSG("File_serve_client %p, flags=%d state=%d\n", + (void *) client, client->flags, client->state); if (client->flags & (FILE_DONE | FILE_ERR)) break; if (client->flags & FILE_READ) { Then: $ make clean $ make $ sudo make install $ dpidc stop >Speaking of weird errors, here is some glitch-art I made with Dillo, >which introduces corruption into the data stream, resulting in >some interesting jpeg artifacts: > >The original image: >https://alex.envs.net/test/dillo-test1.png > >Glitched: >https://alex.envs.net/test/dillo-glitch-comp1.png >https://alex.envs.net/test/dillo-glitch-comp2.png >https://alex.envs.net/test/dillo-glitch-comp3.png Nice ones! Best, Rodrigo.

Oct. 11, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > Hi, > > On Tue, Oct 08, 2024 at 10:55:37PM +0200, a1ex(a)dismail.de wrote: > >Hi, > > > >Rodrigo Arias <rodarima(a)gmail.com> wrote: > > > >> >$ fltk-config --version > >> >1.3.3 > >> > >> I suspect the glich may be related to this old FLTK version. Can > >> you reproduce the bug with the last FLTK 1.3.9 release? You may > >> need to install it from source. > > > >Just tried, but getting some linker errors building Dillo with it. > >Would probably need some patches to make that version work on > >OpenBSD, maybe thats why they are still stuck on an older version of > >FLTK. I managed to get the newer FLTK working and built Dillo with it, but unfortunately it doesn't fix the view-source glitch or the image rendering problem. > >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 > >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 > >READ Failed with -1: Connection reset by peer > > Can you place a breakpoint in GDB here and print the backtrace (bt)? > It may be interesting to see how we arrive at this reset error. I'm not exactly sure how to set the breakpoint for that specific event, but I managed to get a more detailed backtrace which might be useful (see attached). > With a corrupted heap you will see all kind of weird errors. Use > Valgrind to get an idea of where things start to go wrong. Thanks, I will try to give Valgrind a shot soon. Speaking of weird errors, here is some glitch-art I made with Dillo, which introduces corruption into the data stream, resulting in some interesting jpeg artifacts: The original image: https://alex.envs.net/test/dillo-test1.png Glitched: https://alex.envs.net/test/dillo-glitch-comp1.png https://alex.envs.net/test/dillo-glitch-comp2.png https://alex.envs.net/test/dillo-glitch-comp3.png Regards, Alex

Oct. 9, 2024

Re: Rendering issue with view source and large embedded images

by Rodrigo Arias

Hi, On Tue, Oct 08, 2024 at 10:55:37PM +0200, a1ex(a)dismail.de wrote: >Hi, > >Rodrigo Arias <rodarima(a)gmail.com> wrote: > >> >$ fltk-config --version >> >1.3.3 >> >> I suspect the glich may be related to this old FLTK version. Can you >> reproduce the bug with the last FLTK 1.3.9 release? You may need to >> install it from source. > >Just tried, but getting some linker errors building Dillo with it. >Would probably need some patches to make that version work on OpenBSD, >maybe thats why they are still stuck on an older version of FLTK. > >ld: error: undefined symbol: Fl_Display_Device::display_device() >>>> referenced by fltkviewbase.cc >>>> libDw_fltk_a-fltkviewbase.o:(dw::fltk::FltkViewBase::draw(dw::core::Rectangle >>>> const*, dw::fltk::FltkViewBase::DrawType)) in archive >>>> ../dw/libDw-fltk.a > >... Is it possible you have two FLTK versions and it is picking one for the headers and the other at link time? If so, the easiest way is to remove the old version temporarily. I ran into similar problems when I was testing FLTK 1.4: https://github.com/dillo-browser/dillo/issues/258 >> >I now noticed that this page also makes Dillo segfault when I reload >> >it several times: >> >> I think this is a different bug. Still, I cannot reproduce either. >> >> You can try setting VERBOSE to 1 in src/chain.c and rebuilding Dillo. >> That will give you some details of the CCC operations. It seems it is >> trying to abort the client 1 when it was already gone. > >Here is the output of a crash with that set: > >Nav_open_url: new url='file:/tmp/dillo-doublefree.html' >a_Capi_ccc : OpStart [2B] Info=0xebee90cbd00 Flags=0 >a_Dpi_ccc : OpStart [2B] Info=0xebed4db4980 Flags=0 >a_IO_ccc : OpStart [2B] Info=0xebeef295240 Flags=0 >a_Capi_ccc : OpStart [1B] Info=0xebee90ac240 Flags=0 >a_Dpi_ccc : OpStart [1B] Info=0xebee90d20c0 Flags=0 >a_IO_ccc : OpStart [1B] Info=0xebe57007340 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xebe57007340 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xebee90ac240 Flags=0 >a_Capi_ccc : OpSend [2B] Info=0xebee90cbd00 Flags=0 >a_Dpi_ccc : OpSend [2B] Info=0xebed4db4980 Flags=0 >a_IO_ccc : OpSend [2B] Info=0xebeef295240 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xebee90ac240 Flags=0 >a_Capi_ccc : OpSend [1B] Info=0xebee90ac240 Flags=0 >a_Dpi_ccc : OpSend [1B] Info=0xebee90d20c0 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xebe57007340 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_Nav_expect_done: reload! >a_Capi_ccc : OpStart [2B] Info=0xebe57007d40 Flags=0 >a_Dpi_ccc : OpStart [2B] Info=0xebe57007b00 Flags=0 >a_IO_ccc : OpStart [2B] Info=0xebeef2be980 Flags=0 >a_Capi_ccc : OpStart [1B] Info=0xebee90ac440 Flags=0 >a_Dpi_ccc : OpStart [1B] Info=0xebee90ac1c0 Flags=0 >a_IO_ccc : OpStart [1B] Info=0xebee90ace40 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xebee90ace40 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xebee90ac440 Flags=0 >a_Capi_ccc : OpSend [2B] Info=0xebe57007d40 Flags=0 >a_Dpi_ccc : OpSend [2B] Info=0xebe57007b00 Flags=0 >a_IO_ccc : OpSend [2B] Info=0xebeef2be980 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xebee90ac440 Flags=0 >a_Capi_ccc : OpSend [1B] Info=0xebee90ac440 Flags=0 >a_Dpi_ccc : OpSend [1B] Info=0xebee90ac1c0 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xebee90ace40 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_Capi_ccc : OpStart [2B] Info=0xebeef295c00 Flags=0 >a_Dpi_ccc : OpStart [2B] Info=0xebe57007380 Flags=0 >a_IO_ccc : OpStart [2B] Info=0xebe57007e40 Flags=0 >a_Capi_ccc : OpStart [1B] Info=0xebe570072c0 Flags=0 >a_Dpi_ccc : OpStart [1B] Info=0xebeef295080 Flags=0 >a_IO_ccc : OpStart [1B] Info=0xebe57007100 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xebe57007100 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xebe570072c0 Flags=0 >a_Capi_ccc : OpSend [2B] Info=0xebeef295c00 Flags=0 >a_Dpi_ccc : OpSend [2B] Info=0xebe57007380 Flags=0 >a_IO_ccc : OpSend [2B] Info=0xebe57007e40 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xebe570072c0 Flags=0 >a_Capi_ccc : OpSend [1B] Info=0xebe570072c0 Flags=0 >a_Dpi_ccc : OpSend [1B] Info=0xebeef295080 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xebe57007100 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >READ Failed with -1: Connection reset by peer Can you place a breakpoint in GDB here and print the backtrace (bt)? It may be interesting to see how we arrive at this reset error. >a_IO_ccc : OpAbort [2F] Info=0xebeef2be980 Flags=0 >a_Dpi_ccc : OpAbort [2F] Info=0xebe57007b00 Flags=0 >** WARNING **: Unused CCC >READ Failed with -1: Connection reset by peer >a_IO_ccc : OpAbort [2F] Info=0xebe57007e40 Flags=0 >a_Dpi_ccc : OpAbort [2F] Info=0xebe57007380 Flags=0 >** WARNING **: Unused CCC >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xebee90cbd00 Flags=0 >a_IO_ccc : OpEnd [2F] Info=0xebeef295240 Flags=0 >a_Dpi_ccc : OpEnd [2F] Info=0xebed4db4980 Flags=0 >a_Capi_ccc : OpEnd [2F] Info=0xebee90cbd00 Flags=0 >HTTP warning: Content-Length (937694) does NOT match message body >(921310) for file:/tmp/dillo-doublefree.html a_Capi_ccc : OpEnd [1B] >Info=0xebee90ac240 Flags=0 a_Dpi_ccc : OpEnd [1B] >Info=0xebee90d20c0 Flags=0 a_IO_ccc : OpEnd [1B] >Info=0xebe57007340 Flags=0 Nav_open_url: new >url='file:/tmp/dillo-doublefree.html' a_Capi_ccc : OpAbort [1B] >Info=0xebee90ac440 Flags=0 a_Dpi_ccc : OpAbort [1B] >Info=0xebee90ac1c0 Flags=0 a_IO_ccc : OpAbort [1B] >Info=0xebee90ace40 Flags=0 IO_write, closing with pending data not >sent: >"vUdPWpfEOj6lBo+kSy2FykcFntmZoyBGTK+AfTqPzrmKKAOrtNB1Z/B92i6bds8t1BJGoibLLsk5HqOR+dMhtdQv/ >... >a_Capi_ccc : OpAbort [2B] Info=0xebe57007d40 Flags=0 a_Dpi_ccc : >OpAbort [2B] Info=0xebe57007b00 Flags=0 a_IO_ccc : OpAbort [2B] >Info=0xebeef2be980 Flags=-282335104 dillo(19444) in free(): bogus >pointer (double free?) 0xffffffff00000003 Abort trap (core dumped) This is too late, here the heap is already fucked (see the flags). Try running with Valgrind's Memcheck tool and see where the first memory error happens: https://valgrind.org/docs/manual/quick-start.html You may need to rebuild Dillo with ../configure CFLAGS='-Og -g' CXXFLAGS='-Og -g' to see the backtrace properly. > >--- > >Also, when trying to view the source of the test page, I get this crash: > >Nav_open_url: new url='dpi:/vsource/:file:/tmp/dillo-doublefree.html' >a_Capi_ccc : OpStart [2B] Info=0xfabc093a700 Flags=0 >a_Dpi_ccc : OpStart [2B] Info=0xfac19738080 Flags=0 >a_IO_ccc : OpStart [2B] Info=0xfabc093a740 Flags=0 >a_Capi_ccc : OpStart [1B] Info=0xfac1973f380 Flags=0 >a_Dpi_ccc : OpStart [1B] Info=0xfac1973ff40 Flags=0 >a_IO_ccc : OpStart [1B] Info=0xfabc093a780 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xfabc093a780 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xfac1973f380 Flags=0 >a_Capi_ccc : OpSend [2B] Info=0xfabc093a700 Flags=0 >a_Dpi_ccc : OpSend [2B] Info=0xfac19738080 Flags=0 >a_IO_ccc : OpSend [2B] Info=0xfabc093a740 Flags=0 >a_Capi_ccc : OpSend [1F] Info=0xfac1973f380 Flags=0 >a_Capi_ccc : OpSend [1B] Info=0xfac1973f380 Flags=0 >a_Dpi_ccc : OpSend [1B] Info=0xfac1973ff40 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xfabc093a780 Flags=0 >a_Capi_ccc : OpSend [1B] Info=0xfac1973f380 Flags=0 >a_Dpi_ccc : OpSend [1B] Info=0xfac1973ff40 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xfabc093a780 Flags=0 >a_Capi_ccc : OpSend [1B] Info=0xfac1973f380 Flags=0 >a_Dpi_ccc : OpSend [1B] Info=0xfac1973ff40 Flags=0 >a_IO_ccc : OpSend [1B] Info=0xfabc093a780 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xfabc093a740 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xfac19738080 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xfabc093a700 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xfabc093a700 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xfabc093a740 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xfac19738080 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xfabc093a700 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xfabc093a740 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xfac19738080 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xfabc093a700 Flags=0 >a_IO_ccc : OpSend [2F] Info=0xfabc093a740 Flags=0 >a_Dpi_ccc : OpSend [2F] Info=0xfac19738080 Flags=0 >a_Capi_ccc : OpSend [2F] Info=0xfabc093a700 Flags=0 >XRequest.139: BadLength (poly request too large or internal Xlib length >error) 0x2800006 [xcb] Unknown sequence number while processing queue >[xcb] You called XInitThreads, this is not your fault >[xcb] Aborting, sorry about that. >assertion "!xcb_xlib_threads_sequence_lost" failed: file >"/usr/xenocara/lib/libX11/src/xcb_io.c", line 281, function >"poll_for_event" [dpip]: [Dpip_dsh_write] Broken pipe [dpip]: >[Dpip_dsh_write] Broken pipe [dpip]: [Dpip_dsh_write] Broken pipe >Abort trap (core dumped) With a corrupted heap you will see all kind of weird errors. Use Valgrind to get an idea of where things start to go wrong. Best, Rodrigo.

Oct. 8, 2024