Re: tunables signed/unsigned bug & patch

[Carlos O'Donell <carlos at redhat dot com>]

On 01/19/2017 02:37 PM, Carlos O'Donell wrote:
> This also IMO needs a regression test.
> 
> e.g.
> 
> - Create test malloc/tst-malloc-tunables.c
>   - Test calls mallopt to verify internal malloc parameter
>     was set to non-default size_t value using tunable.

For some reason I thought mallopt would return the old value
via the return, but it clearly doesn't. My mistake.

> - Add test to malloc/Makefile.
> - Set tunable with 'tst-malloc-tunables-ENV = GLIBC_TUNABLES=glibc.malloc.foo=x'
 
So the only way you can verify tunables is by indirect observation.

The easiest to test is MALLOC_ARENA_MAX which is a SIZE_T.

Set it to 1 (a value which will never result from even a 1 CPU system).

Spawn one thread per cpu and have them call malloc free in a tight loop.

Once all threads are running call malloc_info to count <heap> elements
(arenas).

If heaps > 1, then FAIL the test, clearly we didn't set arena max.

If heaps == 1, then it could be a false negative, the test has failed
to set arena max, and the threads managed to avoid each other such that
a second heap was never created (vanishingly unlikely).

So this gives you a relatively robust test that will very likely catch
the problem we saw.

The only _real_ way to fix this is to expose a GLIBC_PRIVATE symbols
which allow access to get/set the tunables.

-- 
Cheers,
Carlos.