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.