On 25 July 2017 at 15:52, James Cowgill <[email protected]> wrote: > Hi, > > [moved to [email protected]] > > 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
