Re: Maximum threads reached on mips and mipsel buildds?
On 25 July 2017 at 15:52, James Cowgill <jcowgill@debian.org> wrote:
> Hi,
>
> [moved to debian-mips@l.d.o]
>
> On 24/07/17 22:48, Steven Capper wrote:
>> Hi,
>> I've been tweaking my tbb package for Buster, and have upgraded to
>> latest upstream release and am closing off a few bugs.
>>
>> One thing I noticed is a strange failure mode for 2017~U7-2
>> (targetting sid) on the mips and mipsel buildds. Logs at:
>> https://buildd.debian.org/status/fetch.php?pkg=tbb&arch=mips&ver=2017~U7-2&stamp=1500818436&raw=0
>> and,
>> https://buildd.debian.org/status/fetch.php?pkg=tbb&arch=mipsel&ver=2017~U7-2&stamp=1500865997&raw=0
>>
>> (mips64el appears to work fine)
>>
>> The failure mode is:
>>
>> ./test_malloc_pools.exe 1:4
>> Call stack info (6):
>> ./test_malloc_pools.exe(_Z16print_call_stackv+0x8c)[0x5565ea78]
>> ./test_malloc_pools.exe(_Z11ReportErrorPKciS0_S0_+0x40)[0x5565ec1c]
>> ./test_malloc_pools.exe(_Z19TestFixedBufferPoolv+0x828)[0x55660b60]
>> ./test_malloc_pools.exe(_Z8TestMainv+0x64)[0x55662af8]
>> ./test_malloc_pools.exe(main+0x98)[0x5565e2d8]
>> /lib/mipsel-linux-gnu/libc.so.6(__libc_start_main+0x108)[0x778ed4c8]
>> ../../src/test/harness.h:530, assertion 0==status: NativeParallelFor:
>> pthread_create failed
>
> Running it in strace gives:
>> clone(child_stack=0x7f045ff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f0464f8, tls=0x7f04d920, child_tidptr=0x7f0464f8) = 16753
>> mmap2(NULL, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f047000
>> mprotect(0x7f047000, 4096, PROT_NONE) = 0
>> clone(child_stack=0x7f445ff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f4464f8, tls=0x7f44d920, child_tidptr=0x7f4464f8) = 16754
>> mmap2(NULL, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f447000
>> mprotect(0x7f447000, 4096, PROT_NONE) = 0
>> clone(child_stack=0x7f845ff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f8464f8, tls=0x7f84d920, child_tidptr=0x7f8464f8) = 16755
>> mmap2(NULL, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = -1 ENOMEM (Cannot allocate memory)
>
> Which means it probably run out of virtual memory to allocate any more
> stacks. Since 32-bit mips is limited to 2GB of virtual memory and the
> default stack size is 4MB, this places an upper limit on the number of
> threads per process at 512. In practice it will be smaller than that
> since we have to store the heap, executables etc.
>
Thank you James,
Rather embarrassingly I hadn't even considered the VA space size :-).
I can (and should) bring the default stack size down to 1MB for 32-bit
mips. I will also double check whether or not I've introduced a
regression in the packaging, as I think earlier versions of this
package worked on 32-bit mips.
Cheers,
--
Steve
Reply to: