Valgrind has tipped over from seeing the keep-alive thread as possibly
leaked to seeing it as definitely leaked. We can suppress both.
An alternative here is "all" or to just remove the line. For the moment
I think this is best, as we're still excluding indirect leaks this way.
I'd want to think a bit whether it made sense for the keep-alive thread
to indirectly leak anything, so I'd like it to fail if it comes up.
Change-Id: Ib28790a1d84a0a9061fdb6de48569ca8ea51b52a
Reviewed-on: https://skia-review.googlesource.com/8764
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
It appears that the top-level function named has switched to just "main"
Change-Id: I33a18a8d433867e759312d09e5b258f934f495a4
Reviewed-on: https://skia-review.googlesource.com/8194
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This is a follow up to building the Valgrind bots with GN.
It's not clear why these need to leak, but we might as well
update the suppressions. The stacks now look like this:
Memcheck:Leak
match-leak-kinds: possible
fun:calloc
fun:_dl_allocate_tls
fun:pthread_create@@GLIBC_2.2.5
fun:_ZN8SkThreadC1EPFvPvES0_
fun:_Z14nanobench_mainv
fun:(below main)
We suppress fun:main in that last slot, so just make it ...
TBR=
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2347153002
Review-Url: https://codereview.chromium.org/2347153002
The fixes are in the updated libjpeg-turbo repository
pulled in by DEPS. The fixes are detailed in the linked
skia bug. To summarize briefly, we now use calloc()
instead of malloc().
BUG=skia:4030
Review URL: https://codereview.chromium.org/1237213004
FontConfig uses offsets for elements instead of pointers, so any value
held by an element goes missing from memory checkers. Previous
suppressions took care of rule copies and adds to elements, but value
lists may be copied as well. When they are, values are copied, including
the content of strings and matricies. Since value lists are effectively
like Fc*Add functions (even calling the same underlying helpers), treat
them as such and suppress any 'leaks' they may cause.
Review URL: https://codereview.chromium.org/894863003
Reason for revert:
Leaks, leaks, leaks.
Original issue's description:
> SkThreadPool ~~> SkTaskGroup
>
> SkTaskGroup is like SkThreadPool except the threads stay in
> one global pool. Each SkTaskGroup itself is tiny (4 bytes)
> and its wait() method applies only to tasks add()ed to that
> instance, not the whole thread pool.
>
> This means we don't need to bring up new thread pools when
> tests themselves want to use multithreading (e.g. pathops,
> quilt). We just create a new SkTaskGroup and wait for that
> to complete. This should be more efficient, and allow us
> to expand where we use threads to really latency sensitive
> places. E.g. we can probably now use these in nanobench
> for CPU .skp rendering.
>
> Now that all threads are sharing the same pool, I think we
> can remove most of the custom mechanism pathops tests use
> to control threading. They'll just ride on the global pool
> with all other tests now.
>
> This (temporarily?) removes the GPU multithreading feature
> from DM, which we don't use.
>
> On my desktop, DM runs a little faster (57s -> 55s) in
> Debug, and a lot faster in Release (36s -> 24s). The bots
> show speedups of similar proportions, cutting more than a
> minute off the N4/Release and Win7/Debug runtimes.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6fR=caryclark@google.com, bsalomon@google.com, bungeman@google.com, reed@google.com, mtklein@chromium.orgTBR=bsalomon@google.com, bungeman@google.com, caryclark@google.com, mtklein@chromium.org, reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/533393002
SkTaskGroup is like SkThreadPool except the threads stay in
one global pool. Each SkTaskGroup itself is tiny (4 bytes)
and its wait() method applies only to tasks add()ed to that
instance, not the whole thread pool.
This means we don't need to bring up new thread pools when
tests themselves want to use multithreading (e.g. pathops,
quilt). We just create a new SkTaskGroup and wait for that
to complete. This should be more efficient, and allow us
to expand where we use threads to really latency sensitive
places. E.g. we can probably now use these in nanobench
for CPU .skp rendering.
Now that all threads are sharing the same pool, I think we
can remove most of the custom mechanism pathops tests use
to control threading. They'll just ride on the global pool
with all other tests now.
This (temporarily?) removes the GPU multithreading feature
from DM, which we don't use.
On my desktop, DM runs a little faster (57s -> 55s) in
Debug, and a lot faster in Release (36s -> 24s). The bots
show speedups of similar proportions, cutting more than a
minute off the N4/Release and Win7/Debug runtimes.
BUG=skia:
R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/531653002
