Re: Bug#727009: FTBFS on kfreebsd-i386: FAIL: test-pangocairo-threads
On 29/10/13 00:46, Emilio Pozuelo Monfort wrote: On 28/10/13 23:49, Steven Chamberlain wrote: On 28/10/13 14:33, Emilio Pozuelo Monfort wrote: The test is trying to create 100 threads, but pthread_create returns EAGAIN because it hits some limit, which makes g_thread_new() abort (as stated in the docs, g_thread_try_new() wouldn't abort but return NULL). The question is, why are we hitting the limit so soon here? Not sure yet but this reminds me of bug #725516: lbzip2: unable to create a POSIX thread: Resource temporarily unavailable Indeed, looks very similar. It's also failing consistently when ran as `make check' but works most of the time when invoked directly. FWIW we run autoreconf at the beginning of the build so we're using latest automake as available in Debian (1.14 in this case). Any news here? This is blocking pango's migration and the harfbuzz transition. Emilio -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527a0752.6030...@debian.org
Re: Bug#727009: FTBFS on kfreebsd-i386: FAIL: test-pangocairo-threads
Hi, On 06/11/13 09:09, Emilio Pozuelo Monfort wrote: Any news here? This is blocking pango's migration and the harfbuzz transition. I found this is caused by 'make' raising RLIMIT_STACK from the default setting of 8192k to its maximum, 65536k. It is reproducible from the shell by setting ulimit -s 65536 before running the test program directly. I don't know if this is an eglibc bug or expected behaviour (and therefore a 'make' bug) so I am Cc'ing Petr. In the successful case, creation of each thread involves an mmap of len 0x80 (8192k) by the parent: pango1.0-1.36.0/debian/build/shared/tests$ ktrace -di -- ./test-pangocairo-threads 52374 100417 lt-test-pangocairo- CALL thr_new(0xc2ec,0x34) 52374 100417 lt-test-pangocairo- RET thr_new 0 52374 100417 lt-test-pangocairo- CALL mmap(0,0x80,0x7PROT_READ|PROT_WRITE|PROT_EXEC,0x1002MAP_ANON|MAP_TYPE|MAP_PRIVATE,0x,0,0) 52374 100417 lt-test-pangocairo- RET mmap 693108736/0x2950 52374 100417 lt-test-pangocairo- CALL mprotect(0x2950,0x1000,0PROT_NONE) 52374 100417 lt-test-pangocairo- RET mprotect 0 The failure case (when invoked by 'make') involves an mmap of len 0x400 instead (65536k) as each thread is created: pango1.0-1.36.0/debian/build/shared/tests$ ktrace -di -- make check 51903 100859 lt-test-pangocairo- CALL thr_new(0xc10c,0x34) 51903 100859 lt-test-pangocairo- RET thr_new 0 51903 100859 lt-test-pangocairo- CALL mmap(0,0x400,0x7PROT_READ|PROT_WRITE|PROT_EXEC,0x1002MAP_ANON|MAP_TYPE|MAP_PRIVATE,0x,0,0) 51903 100859 lt-test-pangocairo- RET mmap 751828992/0x2cd0 51903 100859 lt-test-pangocairo- CALL mprotect(0x2cd0,0x1000,0PROT_NONE) 51903 100859 lt-test-pangocairo- RET mprotect 0 On kfreebsd-i386 only, this reproducibly fails at thread '53' of 100: 51903 100859 lt-test-pangocairo- RET thr_new 0 51903 100859 lt-test-pangocairo- CALL mmap(0,0x400,0x7PROT_READ|PROT_WRITE|PROT_EXEC,0x1002MAP_ANON|MAP_TYPE|MAP_PRIVATE,0x,0,0) 51903 100859 lt-test-pangocairo- RET mmap -1 errno 12 Cannot allocate memory 51903 100859 lt-test-pangocairo- GIO fd 2 wrote 111 bytes (process:51903): GLib-ERROR **: creating thread '53': Error creating thread: Resource temporarily unavailable Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527aad38.4010...@pyro.eu.org
Re: Bug#727009: FTBFS on kfreebsd-i386: FAIL: test-pangocairo-threads
Hi, On 06/11/13 21:57, Steven Chamberlain wrote: I found this is caused by 'make' raising RLIMIT_STACK from the default setting of 8192k to its maximum, 65536k. It is reproducible from the shell by setting ulimit -s 65536 before running the test program directly. Thanks for the analysis! I don't know if this is an eglibc bug or expected behaviour (and therefore a 'make' bug) so I am Cc'ing Petr. Let's see about that... Regards, Emilio -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527abdb6.3020...@debian.org
Re: Bug#727009: FTBFS on kfreebsd-i386: FAIL: test-pangocairo-threads
I found this is caused by 'make' raising RLIMIT_STACK from the default setting of 8192k to its maximum, 65536k. It is reproducible from the shell by setting ulimit -s 65536 before running the test program directly. Thanks for the analysis! I don't know if this is an eglibc bug or expected behaviour (and therefore a 'make' bug) so I am Cc'ing Petr. Let's see about that... Usual kfreebsd-i386 layout (in MB): start 0 reserved 128 start of code+data segment - usual size 512 MB 640 start of mmaped area 3072 end of user space (at 3 GB) 100 threads x 8 MB = 800 MB - OK 100 threads x 64 MB = 6400 MB - fails 50 threads x 64 MB = 3200 MB - at edge There can be easily 100 currently active threads with default stacks size. There cannot be over 50 active threads with 64 MB stacks. Petr root@bsd32:~# ulimit -a -H socket buffer size (bytes, -b) unlimited core file size (blocks, -c) unlimited data seg size (kbytes, -d) 524288 file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 1 stack size (kbytes, -s) 65536 cpu time (seconds, -t) unlimited max user processes (-u) 3546 virtual memory (kbytes, -v) unlimited root@bsd32:~# cat /proc/self/maps 08048000-08053000 r-xp c000 00:00 70676 /bin/cat 08053000-08054000 r--p c000 00:00 70676 /bin/cat 08054000-08055000 rw-p 1000 00:00 0 28053000-28073000 r-xp 00021000 00:00 23634 /lib/i386-kfreebsd-gnu/ld-2.17.so 28073000-28074000 r--p 00021000 00:00 23634 /lib/i386-kfreebsd-gnu/ld-2.17.so 28074000-28077000 rw-p 3000 00:00 0 28077000-2807e000 r--p 7000 00:00 237512 /etc/ld.so.cache 2807e000-281d3000 r-xp 00159000 00:00 23601 /lib/i386-kfreebsd-gnu/i686/cmov/libc-2.17.so 281d3000-281d5000 r--p 00159000 00:00 23601 /lib/i386-kfreebsd-gnu/i686/cmov/libc-2.17.so 281d5000-281d6000 rw-p 00159000 00:00 23601 /lib/i386-kfreebsd-gnu/i686/cmov/libc-2.17.so 281d6000-282da000 rw-p 00104000 00:00 0 bfbdf000-bfbff000 rwxp 0002 00:00 0 bfbff000-bfc0 r-xp 1000 00:00 0 -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.lnx.2.00.1311070717190.8...@contest.felk.cvut.cz
Re: Bug#727009: FTBFS on kfreebsd-i386: FAIL: test-pangocairo-threads
On 21/10/13 15:54, Michael Biebl wrote: Source: pango1.0 Version: 1.36.0-1 Severity: serious User: debian-bsd@lists.debian.org pango1.0 FTBFS on kfreebsd-i386 when executing the test-suite: /«PKGBUILDDIR»/./test-driver: line 95: 41714 Trace/breakpoint trap $@ $log_file 21 FAIL: test-pangocairo-threads The test is failing with (process:7450): GLib-ERROR **: creating thread '37': Error creating thread: Resource temporarily unavailable The test is trying to create 100 threads, but pthread_create returns EAGAIN because it hits some limit, which makes g_thread_new() abort (as stated in the docs, g_thread_try_new() wouldn't abort but return NULL). The question is, why are we hitting the limit so soon here? ulimit on fischer (where I'm debugging this) reports: max user processes (-u) 5547 so I doubt we're hitting the maximum number of threads here. Perhaps the test should use g_thread_try_new() and retry a limited number of times on EAGAIN. Regards, Emilio -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526e759d.3080...@debian.org
Re: Bug#727009: FTBFS on kfreebsd-i386: FAIL: test-pangocairo-threads
On 28/10/13 14:33, Emilio Pozuelo Monfort wrote: The test is trying to create 100 threads, but pthread_create returns EAGAIN because it hits some limit, which makes g_thread_new() abort (as stated in the docs, g_thread_try_new() wouldn't abort but return NULL). The question is, why are we hitting the limit so soon here? Not sure yet but this reminds me of bug #725516: lbzip2: unable to create a POSIX thread: Resource temporarily unavailable Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526ee9e2.40...@pyro.eu.org
Re: Bug#727009: FTBFS on kfreebsd-i386: FAIL: test-pangocairo-threads
On 28/10/13 23:49, Steven Chamberlain wrote: On 28/10/13 14:33, Emilio Pozuelo Monfort wrote: The test is trying to create 100 threads, but pthread_create returns EAGAIN because it hits some limit, which makes g_thread_new() abort (as stated in the docs, g_thread_try_new() wouldn't abort but return NULL). The question is, why are we hitting the limit so soon here? Not sure yet but this reminds me of bug #725516: lbzip2: unable to create a POSIX thread: Resource temporarily unavailable Indeed, looks very similar. It's also failing consistently when ran as `make check' but works most of the time when invoked directly. FWIW we run autoreconf at the beginning of the build so we're using latest automake as available in Debian (1.14 in this case). -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/526ef770.2040...@debian.org
