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.
_______________________________________________
Dillo-dev mailing list -- dillo-dev@mailman3.com
To unsubscribe send an email to dillo-dev-le...@mailman3.com
