October 2024 - Dillo-dev - lists.mailman3.com

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

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

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 ... > >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 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) --- 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) -Alex

Oct. 8, 2024

Re: Rendering issue with view source and large embedded images

by Rodrigo Arias

Hi, >Yeah, it seems to happen every time the same. > >$ 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. >I saved the above page to a local file, and am using that for testing. > >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. >** WARNING **: CCC: call on already finished chain. Flags=CCC_Ended This is not good^ >CCC_Aborted a_Nav_expect_done: reload! >READ Failed with -1: Connection reset by peer >** WARNING **: Unused CCC >... Best, Rodrigo.

Oct. 8, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

> I now noticed that this page also makes Dillo segfault when I reload > it several times: Sorry maybe I should be more clear. This is when I reload the actual page, not the vsource.

Oct. 8, 2024

Re: Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > >This is an example of a page which uses large embedded jpegs: > >https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html > >When you view the source in Dillo, the issue should be evident. > > I cannot reproduce this (attached). Does it always happens to you? > Which FLTK version are you on? Yeah, it seems to happen every time the same. $ fltk-config --version 1.3.3 I saved the above page to a local file, and am using that for testing. I now noticed that this page also makes Dillo segfault when I reload it several times: ** WARNING **: CCC: call on already finished chain. Flags=CCC_Ended CCC_Aborted a_Nav_expect_done: reload! READ Failed with -1: Connection reset by peer ** WARNING **: Unused CCC WRITE Failed with -1: Connection reset by peer ** WARNING **: Maximum number of classes per element exceeded. ** WARNING **: Maximum number of classes per element exceeded. ** WARNING **: Maximum number of classes per element exceeded. ** WARNING **: Maximum number of classes per element exceeded. ** WARNING **: Maximum number of classes per element exceeded. HTTP warning: Content-Length (657000) does NOT match message body (640616) for file:/tmp/dillo-vsource-overflow.html WRITE Failed with -1: Broken pipe Nav_open_url: new url='file:/tmp/dillo-vsource-overflow.html' dillo(27095) in free(): double free 0x4f5cf02b980 Abort trap (core dumped) EXIT: 134 backtrace: #0 thrkill () at /tmp/-:2 No locals. #1 0x3d7553619f488131 in ?? () No symbol table info available. #2 0x000003f2234105ab in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 sa = {__sigaction_u = {__sa_handler = 0x3000000010, __sa_sigaction = 0x3000000010}, sa_mask = 1035724304, sa_flags = 30747} mask = 4294967263 #3 0x000003f2233df3e4 in wrterror (d=0x3f23a5428f8, msg=0x3f223341697 "double free %p") at /usr/src/lib/libc/stdlib/malloc.c:378 ap = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x781b3dbbe710, reg_save_area = 0x781b3dbbe610}} saved_errno = 9 #4 0x000003f2233e0f09 in ofree (argpool=<optimized out>, p=<optimized out>, clear=<optimized out>, check=<optimized out>, argsz=<optimized out>out>) at /usr/src/lib/libc/stdlib/malloc.c:1690 pool = 0x3f23a5428f8 saved_function = 0xb86fc82ea4cf34f8 <error: Cannot access memory at address 0xb86fc82ea4cf34f8> r = <optimized out> sz = <optimized out> #5 0x000003f2233e0633 in _libc_free (ptr=0x3f192293480) at /usr/src/lib/libc/stdlib/malloc.c:1747 saved_errno = 9 d = 0x3f23a5428f8 #6 0x000003ef75793a5b in a_Chain_bcb (Op=0, Info=<optimized out>, Data1=0x781b3dbbe460, Data2=0x0) at chain.c:139 ret = <error reading variable ret (Cannot access memory at address 0x0)> #7 0x000003ef757d967b in a_Dpi_ccc (Op=5, Branch=2, Dir=2, Info=0x3f1a76eef40, Data1=<optimized out>, Data2=0x0) at dpi.c:745 SockFD = <error reading variable SockFD (Cannot access memory at address 0xffffffffffffffff)> conn = <optimized out> st = <optimized out> #8 0x000003ef75793a5b in a_Chain_bcb (Op=0, Info=<optimized out>, Data1=0x781b3dbbe460, Data2=0x0) at chain.c:139 ret = <error reading variable ret (Cannot access memory at address 0x0)> #9 0x000003ef7579acb3 in a_Capi_ccc (Op=<optimized out>, Branch=<optimized out>, Dir=<optimized out>, Info=<optimized out>, Data1=<optimized out>, Data2=<optimized out>) at capi.c:754 conn = 0x3f17c4a0240 dbuf = <optimized out> finished = <optimized out> #10 0x000003ef7579bea0 in a_Capi_stop_client (Key=6, force=4) at capi.c:630 Client = 0x0 #11 0x000003ef7578a91b in a_Bw_stop_clients (bw=0x3f1f1195280, flags=<optimized out>) at bw.c:197 data = 0x0 #12 0x000003ef757873cc in a_UIcmd_close_bw () No symbol table info available. #13 0x000003ef75787678 in a_UIcmd_close_all_bw () No symbol table info available. #14 0x000003f18adea990 in Fl::wait(double) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #15 0x000003f18adeac4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #16 0x000003ef75782365 in main () No symbol table info available. And here is a different one: [New process 402078] Core was generated by `dillo'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00000fcc9d2228e8 in IO_close_fd (io=0x43203a6f6c6c6944, CloseCode=<optimized out>) at IO.c:134 134 if ((CloseCode == IO_StopRdWr) && io->FD != -1) { (gdb) bt full #0 0x00000fcc9d2228e8 in IO_close_fd (io=0x43203a6f6c6c6944, CloseCode=<optimized out>) at IO.c:134 events = <error reading variable events (Cannot access memory at address 0x0)> #1 a_IO_ccc (Op=5, Branch=<optimized out>, Dir=2, Info=0xfcef07b3a80, Data1=<optimized out>, Data2=0x0) at IO.c:440 io = 0x43203a6f6c6c6944 dbuf = <optimized out> newline = <optimized out> msglen = <optimized out> #2 0x00000fcc9d1dba5b in a_Chain_bcb (Op=-1659262356, Info=<optimized out>, Data1=0xfcef07b3a80, Data2=0x0) at chain.c:139 ret = <error reading variable ret (Cannot access memory at address 0x0)> #3 0x00000fcc9d22167b in a_Dpi_ccc (Op=5, Branch=2, Dir=2, Info=0xfcef07b3480, Data1=<optimized out>, Data2=0x0) at dpi.c:745 SockFD = <error reading variable SockFD (Cannot access memory at address 0xffffffffffffffff)> conn = <optimized out> st = <optimized out> #4 0x00000fcc9d1dba5b in a_Chain_bcb (Op=-1659262356, Info=<optimized out>, Data1=0xfcef07b3a80, Data2=0x0) at chain.c:139 ret = <error reading variable ret (Cannot access memory at address 0x0)> #5 0x00000fcc9d1e2cb3 in a_Capi_ccc (Op=<optimized out>, Branch=<optimized out>, Dir=<optimized out>, Info=<optimized out>, Data1=<optimized out>, Data2=<optimized out>) at capi.c:754 conn = 0xfcef07bc180 dbuf = <optimized out> finished = <optimized out> #6 0x00000fcc9d1e3ea0 in a_Capi_stop_client (Key=2, force=4) at capi.c:630 Client = 0x1 #7 0x00000fcc9d1d291b in a_Bw_stop_clients (bw=0xfcf6f89ef80, flags=<optimized out>) at bw.c:197 data = 0x1 #8 0x00000fcc9d1cf3cc in a_UIcmd_close_bw () No symbol table info available. #9 0x00000fcc9d1d072f in win_cb(Fl_Widget*, void*) () No symbol table info available. #10 0x00000fcebc80351e in Fl_Widget::do_callback(Fl_Widget*, void*) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #11 0x00000fcebc79a23b in Fl::handle_(int, Fl_Window*) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #12 0x00000fcebc80c83b in fl_handle(_XEvent const&) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #13 0x00000fcebc808f40 in do_queued_events() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #14 0x00000fcebc808e88 in fl_wait(double) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #15 0x00000fcebc798a6e in Fl::wait(double) () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #16 0x00000fcebc798c4d in Fl::run() () from /usr/local/lib/libfltk.so.8.0 No symbol table info available. #17 0x00000fcc9d1ca365 in main () No symbol table info available. > Should not be related, but I notice that you are using the old DPI > for vsource, as I changed the style a while back. Have you done `make > install` and set the dpi_dir in ~/.dillo/dpidrc properly? I suspect > it may be picking up another install. Yeah, thats true I was using an older vsource dpi. But, I did a new clean install of everything and still see the issue. Maybe its OpenBSD related, or something else weird with my setup. I'm open to suggestions :) Regards, Alex

Oct. 8, 2024

Re: Rendering issue with view source and large embedded images

by Rodrigo Arias

Hi Alex, On Tue, Oct 08, 2024 at 12:01:38AM +0200, a1ex(a)dismail.de wrote: >Hi, > >There is a small rendering glitch when trying to view the source of a >page which has larger embedded data uri images. See attached screenshot. > >This is an example of a page which uses large embedded jpegs: >https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html >When you view the source in Dillo, the issue should be evident. I cannot reproduce this (attached). Does it always happens to you? Which FLTK version are you on? Should not be related, but I notice that you are using the old DPI for vsource, as I changed the style a while back. Have you done `make install` and set the dpi_dir in ~/.dillo/dpidrc properly? I suspect it may be picking up another install. >Since the encoded image is just one super-long line in the html, the >vsource dpi probably isn't designed to handle that. > >I don't think its typical that a site will embed large images into the >page like this, but maybe its still worth considering. I see the case for the data: images patch now. Anyway, nice blog post. Best, Rodrigo.

Oct. 8, 2024

Rendering issue with view source and large embedded images

by a1ex＠dismail.de

Hi, There is a small rendering glitch when trying to view the source of a page which has larger embedded data uri images. See attached screenshot. This is an example of a page which uses large embedded jpegs: https://www.da.vidbuchanan.co.uk/blog/dram-emfi.html When you view the source in Dillo, the issue should be evident. Since the encoded image is just one super-long line in the html, the vsource dpi probably isn't designed to handle that. I don't think its typical that a site will embed large images into the page like this, but maybe its still worth considering. Regards, Alex

Oct. 7, 2024

Re: Navigation by pages

by a1ex＠dismail.de

Hi Rodrigo, Rodrigo Arias <rodarima(a)gmail.com> wrote: > You can do this by clicking on the scroll bar, above and below the > "thumb". > > https://dillo-browser.github.io/user_help.html#scrolling > > Does that work for you? Thanks, somehow I have been ignorant of that feature for all these years. :) 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. Regards, Alex

Oct. 6, 2024