We were using integer multiplication rather than fixed-point
multiplication when calculating point sizes relative to the viewport.
This fixes that.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
In order to help us debug shutting down with active fetches, this
will abort the process cleanly if we get a callback to an "active"
llcache handle after the abort process has actually killed them
all. This can happen with deferred fetcher aborts in the cURL
fetcher.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
During the process of finalising the hlcache, there won't be
any more fetching going on. As such, we can abort, error, and
then destroy any contents still in the process of loading. This
should reduce our leaks during shutdown.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
Sometimes callbacks may be cancelled from within themselves. In
that case we need to simply ensure that should the callback be
wanted to repeat, we instead stop that so that once the callback
is completed we do not attempt to reschedule something which had
already been deleted.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
In order to cope better with modern cURL which prevents making
cURL calls when inside a callback from within cURL, defer fetch
start when we are processing in `fetch_curl_data()`.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
The pushed fragment node holds the reference, so unref it in
the end of createDocumentFragment()
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
Since executing a script can cause more scripts to be appended
to the script array, and that can cause a reallocation which might
move the script array, reacquire the script pointer after running
the script so that we don't wander off into the reeds.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
stop curl fetcher logging being special case to standard error and
use the fetch catagory at DEBUG level instead.
The special suppress_curl_debug option is currently still obeyed
Until we can determine *how* the compartment isn't cleaning
up properly in the duktape context, this will at least mean
we don't get unpleasant callback related issues when compartments
are reset during browsing.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
On ubuntu 19.4, curl is built with HTTP2 support, and we
segfault.
==18174== Invalid read of size 1
==18174== at 0x4ACCE7D: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.5.0)
==18174== by 0x4B054B1: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.5.0)
==18174== by 0x4AD398A: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.5.0)
==18174== by 0x4AD7A0B: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.5.0)
==18174== by 0x4AE93EE: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.5.0)
==18174== by 0x4AEA8A8: curl_multi_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.5.0)
==18174== by 0x1F2EF7: fetch_curl_poll (curl.c:1209)
==18174== by 0x1EEC5C: fetcher_poll (fetch.c:271)
==18174== by 0x2A1ED4: schedule_run (schedule.c:160)
==18174== by 0x15F941: framebuffer_run (gui.c:596)
==18174== by 0x15F941: main (gui.c:2206)
==18174== Address 0x9de95a8 is 3,224 bytes inside a block of size 6,304 free'd
==18174== at 0x483997B: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==18174== by 0x4AD497B: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.5.0)
==18174== by 0x4AE158C: curl_easy_cleanup (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.5.0)
==18174== by 0x1F30DE: fetch_curl_cache_handle (curl.c:761)
==18174== by 0x1F30DE: fetch_curl_stop (curl.c:840)
==18174== by 0x1F30DE: fetch_curl_done (curl.c:1122)
==18174== by 0x1F30DE: fetch_curl_poll (curl.c:1223)
==18174== by 0x1EEC5C: fetcher_poll (fetch.c:271)
==18174== by 0x2A1ED4: schedule_run (schedule.c:160)
==18174== by 0x15F941: framebuffer_run (gui.c:596)
==18174== by 0x15F941: main (gui.c:2206)
==18174== Block was alloc'd at
==18174== at 0x483AB35: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==18174== by 0x4AE165F: curl_easy_duphandle (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.5.0)
==18174== by 0x1F15EB: fetch_curl_get_handle (curl.c:738)
==18174== by 0x1F15EB: fetch_curl_start (curl.c:750)
==18174== by 0x1EEB22: fetch_dispatch_job (fetch.c:156)
==18174== by 0x1EEB22: fetch_choose_and_dispatch (fetch.c:187)
==18174== by 0x1EEB22: fetch_dispatch_jobs (fetch.c:247)
==18174== by 0x1EF1BB: fetch_start (fetch.c:573)
==18174== by 0x26C779: llcache_object_refetch (llcache.c:916)
==18174== by 0x26D5E4: llcache_object_fetch (llcache.c:979)
==18174== by 0x26D5E4: llcache_object_retrieve_from_cache (llcache.c:1767)
==18174== by 0x26D5E4: llcache_object_retrieve (llcache.c:1865)
==18174== by 0x26E42C: llcache_fetch_redirect (llcache.c:2110)
==18174== by 0x26E42C: llcache_fetch_callback (llcache.c:2810)
==18174== by 0x1F1295: fetch_curl_process_headers (curl.c:922)
==18174== by 0x1F13A0: fetch_curl_data (curl.c:1324)
==18174== by 0x4ACD4C3: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.5.0)
==18174== by 0x4AE00DA: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.5.0)
