Re: cbmc: FTBFS[kfreebsd,hurd]: GCC-4.7
tags 673579 + pending thanks Hi (I added Michael Taautschnig directly to the loop) On Sat, May 19, 2012 at 11:25:41PM +0100, Steven Chamberlain wrote: tags 673579 + patch thanks On 19/05/12 23:02, Christoph Egger wrote: Steven Chamberlain ste...@pyro.eu.org writes: #if defined(__linux__) || defined(__GNU__) || defined(__GLIBC__) __GLIBC__ should cover all of them alone. Or alternatively consistently checking for kernels [...] Oh I see, thanks. I think it is the userland we are interested in here so __GLIBC__ sounds right. Please find a patch attached (to apply after KiBi's) which I have tested on kfreebsd-i386. I've no idea if __GLIBC__ exists on __APPLE__ or other non-Debian platforms but I guess we don't need to worry about them, so I've left that alone. Steven, many thanks for pointing to this. Michael, I did the NMU some days ago, trying to help on some RC bugs for wheezy. I will upload the package with the fix again, with DELAYED/2 only. Please let me know if I should cancel, and if you would like to do the upload. Regards, and sorry for the noise Salvatore diff -Nru cbmc-4.1/debian/changelog cbmc-4.1/debian/changelog --- cbmc-4.1/debian/changelog 2012-05-13 14:25:55.0 +0200 +++ cbmc-4.1/debian/changelog 2012-05-20 07:56:05.0 +0200 @@ -1,3 +1,13 @@ +cbmc (4.1-1.2) unstable; urgency=low + + * Non-maintainer upload. + * Update fix-FTBFS-with-gcc-4.7.patch patch. +Fix FTBFS with gcc 4.7 on kfreebsd and hurd. +Thanks to Steven Chamberlain ste...@pyro.eu.org for the patch. +(Closes: #673579) + + -- Salvatore Bonaccorso car...@debian.org Sun, 20 May 2012 07:55:28 +0200 + cbmc (4.1-1.1) unstable; urgency=low * Non-maintainer upload. diff -Nru cbmc-4.1/debian/patches/fix-FTBFS-with-gcc-4.7.patch cbmc-4.1/debian/patches/fix-FTBFS-with-gcc-4.7.patch --- cbmc-4.1/debian/patches/fix-FTBFS-with-gcc-4.7.patch 2012-05-13 14:25:55.0 +0200 +++ cbmc-4.1/debian/patches/fix-FTBFS-with-gcc-4.7.patch 2012-05-20 07:56:05.0 +0200 @@ -4,7 +4,7 @@ Bug-Debian: http://bugs.debian.org/667131 Forwarded: no Author: Cyril Brulebois k...@debian.org -Last-Update: 2012-05-13 +Last-Update: 2012-05-20 --- a/src/ansi-c/c_preprocess.cpp +++ b/src/ansi-c/c_preprocess.cpp @@ -13,7 +13,7 @@ #include string.h -#ifdef __LINUX__ -+#ifdef __linux__ ++#ifdef __GLIBC__ #include unistd.h #endif signature.asc Description: Digital signature
Re: OpenJDK-7 on kFreeBSD (feedback)
On 05/16/2012 11:51 AM, Roger Leigh wrote: On Wed, May 16, 2012 at 07:18:21AM +0200, Christoph Egger wrote: Hi all! Christoph Eggerchrist...@debian.org writes: Christoph Eggerchrist...@debian.org writes: Robert Millanr...@debian.org writes: 2012/5/12 Damien Raude-Morvandraz...@debian.org: Also it might be worth trying with a chroot hosted on kfreebsd 8.1. I tried exactly that and on my stable system openjdk-7 fails exactly as on the buildds in the usntable chroot. Will now try if I can get it running with a 8.3 kernel and check what happens there (keeping the rest on stable, chroot on unstable). It's still failing on this mostly-squeeze-but-8.3-kernel system. I'll try and upgrade piece-after-piece to wheezy and see where it starts to work. Changing kernels did not fix this problem in any way. What did make openjdk-7 compile was switching from stable's sbuild/schroot to wheezy's. I thnk it's rather strange that this does have any effect but did indeed work. Adding Roger as sbuild/schroot maintainer into cc maybe he has some insight on what did notably change between the stable (or rather buildd) version and unstable that might have an impact. Some ideas for checking: 1) Run dpkg-buildpackage by hand to eliminate sbuild as the problem: For both the old and new versions of schroot (example, assuming a session-managed chroot on amd64): SESS=$(schroot -b -c unstable-kfreebsd-amd64-sbuild -n testopenjdk) schroot -u root -c $SESS -- apt-get build-dep openjdk-7 schroot -c $SESS -- apt-get source openjdk-7 schroot -c $SESS -d openjdk-7-$ver -- dpkg-buildpackage -us -uc schroot -e -c $SESS You can also run schroot with -v --debug=notice to see if there is any difference in the user environment when running dpkg-buildpackage. 2) sbuild just runs dpkg-buildpackage, but it's possible that the environment has subtly changed; the buildd version of sbuild is very dated now, and there have been a few changes. It's mainly relating to build-deps though, e.g. we use the apt resolver by default rather than internal. apt is a better resolver, and should behave 100% identically to internal, but it's possible if you're depending on e.g. a virtual package, you might get different concrete packages installed, which could affect your build. Another case where this differs is that internal can't handle multiarch build-deps at all, and never will. sbuild logs a complete list of everything installed by it, so definitely worth looking at that. Regards, Roger Hi Roger I have tried to run dpkg-buildpackage manually inside chroot environment (with schroot-1.4.22-1~bpo60+1) and build failed. Can that version of schroot be a problem ? Is there a debian repository for newer version of schroot package for squeeze ? Best regards Georgi -- 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/4fb8e694.2050...@oles.biz
Re: OpenJDK-7 on kFreeBSD (feedback)
On Sun, May 20, 2012 at 03:41:56PM +0300, Georgi Naplatanov wrote: I have tried to run dpkg-buildpackage manually inside chroot environment (with schroot-1.4.22-1~bpo60+1) and build failed. Can that version of schroot be a problem ? Is there a debian repository for newer version of schroot package for squeeze ? There's 1.5.2-1 in experimental. It should just rebuild for squeeze. I would not expect the schroot version to be a problem though. schroot is after all just a fancy wrapper around chroot(8). If schroot is causing problems, it's likely to be in the process environment or in the chroot environment (mounted filesystems etc.). While different versions of schroot might have slightly different defaults, none of the changes should result in build failures. You could try running schroot with -p to use the environment in your session, rather than a clean one. This would help see if it's a process environment issue. You could try running with chroot(8) directly as root, and eliminate schroot entirely. This wouldn't set up any filesystem mounts or do any other setup. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- 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/20120520135122.gb13...@codelibre.net
Bug#673681: eegdev; FTBFS[kfreebsd]: testsuite failure
Package: src:eegdev Version: 0.2-1 Severity: serious Tags: sid wheezy User: debian-bsd@lists.debian.org Usertags: kfreebsd X-Debbugs-Cc: debian-bsd@lists.debian.org Justification: fails to build from source (but built successfully in the past) Hi! Your package failed to build on the kfreebsd-* buildds: make check-TESTS make[4]: Entering directory `/build/buildd-eegdev_0.2-1-kfreebsd-i386-LGFJWW/eegdev-0.2/tests' PASS: verify-cast.sh PASS: verifysplit PASS: syseegfile *** glibc detected *** /build/buildd-eegdev_0.2-1-kfreebsd-i386-LGFJWW/eegdev-0.2/tests/.libs/lt-sysbiosemi: double free or corruption (out): 0xbfbfdf98 *** Testing biosemi with float data type Aborted (core dumped) *** glibc detected *** /build/buildd-eegdev_0.2-1-kfreebsd-i386-LGFJWW/eegdev-0.2/tests/.libs/lt-sysbiosemi: double free or corruption (out): 0xbfbfdf98 *** Testing biosemi with double data type Aborted (core dumped) FAIL: testfakeact2.sh Testing tobiia PASS: testfaketobiia.sh = 1 of 5 tests failed Please report to nicolas.bourd...@epfl.ch = Full build log at https://buildd.debian.org/status/fetch.php?pkg=eegdevarch=kfreebsd-i386ver=0.2-1stamp=1337329119 Regards Christoph If you have further questions please mail debian-bsd@lists.debian.org -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer -- 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/87k4064vke@hepworth.siccegge.de
Re: Bug#673594: ruby1.8: FTBFS[kfreebsd-*]: test-all hangs/segfaults
found 673594 1.8.7.352-2 tags 673594 + patch thanks Hi, What about using the attached patch to time out the test-all suite if it hangs, as was done for ruby1.9.1, because its exit status is ignored anyway (some failures are expected, on all arches). I think a workaround like this is needed to at least fix the FTBFS since there are security patches and s390x stuff all waiting on it. The version of ruby1.8 in testing seems to already have this problem (it only built for kfreebsd-i386 on the 4th attempt). We can separately follow up on working out why some of the tests hang; probably thread-related races in eglibc and/or the tests themselves. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org diff --git a/debian/control b/debian/control index c8d77e0..db229e5 100644 --- a/debian/control +++ b/debian/control @@ -3,7 +3,7 @@ Section: ruby Priority: optional Maintainer: akira yamada ak...@debian.org Uploaders: Daigo Moriwaki da...@debian.org, Lucas Nussbaum lu...@debian.org, Antonio Terceiro terce...@debian.org -Build-Depends: cdbs (= 0.4.106), debhelper (= 5), autotools-dev, autoconf, m4, quilt (= 0.40), patch, bison, binutils (= 2.14.90.0.7), libgdbm-dev, libncurses5-dev, libreadline-gplv2-dev, tcl-dev, tk-dev, zlib1g-dev, libssl-dev (= 0.9.6b), file +Build-Depends: cdbs (= 0.4.106), debhelper (= 5), autotools-dev, autoconf, m4, quilt (= 0.40), patch, bison, binutils (= 2.14.90.0.7), libgdbm-dev, libncurses5-dev, libreadline-gplv2-dev, tcl-dev, tk-dev, zlib1g-dev, libssl-dev (= 0.9.6b), file, coreutils Standards-Version: 3.9.2 Homepage: http://www.ruby-lang.org/ Vcs-Git: git://git.debian.org/collab-maint/ruby1.8.git diff --git a/debian/rules b/debian/rules index e238759..1456921 100755 --- a/debian/rules +++ b/debian/rules @@ -62,7 +62,7 @@ DEB_MAKE_BUILD_TARGET = all test common-post-build-arch:: ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) - -make test-all + -timeout 1200 make test-all endif
Re: Bug#673594: ruby1.8: FTBFS[kfreebsd-*]: test-all hangs/segfaults
Whereas the buildds experience hangs during some tests, I see segfaults instead. This sometimes happens even before the first test has been run. This small Ruby testcase results in segfault 50% of the time under ruby1.8 1.8.7.358-2, but always succeeds with ruby1.9.1 1.9.3.0-2: require 'thread' Thread.new do foo = bar end (Measured out of 100 runs, on kfreebsd-i386 with 4-way SMP) Attached are outputs from ktrace for a success and from a failure; then I've tried to diff them. There seems to be a race whereby thread0 tries to call thr_kill on thread2, but if that happens too late thread2 will trigger a segfault instead. Regards, -- Steven Chamberlain ste...@pyro.eu.org --- ok.txt 2012-05-20 20:56:17.734917958 +0100 +++ fail.txt2012-05-20 20:58:12.337235026 +0100 @@ -356,7 +356,7 @@ thread0 ruby1.8 RET open 3 thread0 ruby1.8 CALL read(0x3,0xbfbfe61c,0x4) thread0 ruby1.8 GIO fd 3 read 4 bytes - 0x f0be 5f81 |.._.| + 0x d52b 6642 |.+fB| thread0 ruby1.8 RET read 4 thread0 ruby1.8 CALL close(0x3) @@ -411,7 +411,7 @@ thread0 ruby1.8 CALL gettimeofday(0xbfbfe5b8,0) thread0 ruby1.8 RET gettimeofday 0 thread0 ruby1.8 CALL getpid -thread0 ruby1.8 RET getpid 50320/0xc490 +thread0 ruby1.8 RET getpid 50346/0xc4aa thread0 ruby1.8 CALL break(0x808d000) thread0 ruby1.8 RET break 0 thread0 ruby1.8 CALL sigaction(SIGINT,0xbfbfe564,0xbfbfe5b8) @@ -750,65 +750,49 @@ thread2 ruby1.8 RET sigprocmask 0 thread2 ruby1.8 CALL clock_gettime(0,0x28b68eb8) thread2 ruby1.8 RET clock_gettime 0 +thread2 ruby1.8 CALL sigprocmask(SIG_SETMASK,0x28b68e90,0) +thread2 ruby1.8 RET sigprocmask 0 +thread2 ruby1.8 CALL clock_gettime(0,0x28b68f30) +thread2 ruby1.8 RET clock_gettime 0 +thread2 ruby1.8 CALL sigprocmask(SIG_BLOCK,0,0x28b68e80) +thread2 ruby1.8 RET sigprocmask 0 +thread0 ruby1.8 PSIG SIGSEGV caught handler=0x2818ba50 mask=0x8000 code=0x1 +thread2 ruby1.8 CALL sigprocmask(SIG_UNBLOCK,0x28b68ea0,0x28b68e90) +thread2 ruby1.8 RET sigprocmask 0 +thread0 ruby1.8 CALL write(0x2,0xbfbfbf9c,0xb) +thread2 ruby1.8 CALL clock_gettime(0,0x28b68eb8) +thread2 ruby1.8 RET clock_gettime 0 +thread0 ruby1.8 GIO fd 2 wrote 11 bytes + test.rb:4: thread2 ruby1.8 CALL nanosleep(0x28b68eb0,0) -thread0 ruby1.8 CALL thr_kill(thread2,SIG(null)) -thread0 ruby1.8 RET thr_kill 0 -thread2 ruby1.8 RET nanosleep -1 errno 4 Interrupted system call -thread0 ruby1.8 CALL sigprocmask(SIG_SETMASK,0,0xbfbfdc4c) -thread2 ruby1.8 PSIG SIG(null) caught handler=0x28188860 mask=0x7ffefeff code=0x10001 +thread0 ruby1.8 RET write 11/0xb +thread2 ruby1.8 RET nanosleep -1 errno 22 Invalid argument +thread0 ruby1.8 CALL write(0x2,0x2813751f,0x6) +thread2 ruby1.8 CALL clock_gettime(0,0x28b68eb8) +thread0 ruby1.8 GIO fd 2 wrote 6 bytes + [BUG] +thread2 ruby1.8 RET clock_gettime 0 +thread0 ruby1.8 RET write 6 +thread2 ruby1.8 CALL nanosleep(0x28b68eb0,0) +thread2 ruby1.8 RET nanosleep -1 errno 22 Invalid argument +thread0 ruby1.8 CALL write(0x2,0xbfbf98a0,0x12) +thread2 ruby1.8 CALL clock_gettime(0,0x28b68eb8) +thread0 ruby1.8 GIO fd 2 wrote 18 bytes + Segmentation fault +thread2 ruby1.8 RET clock_gettime 0 +thread0 ruby1.8 RET write 18/0x12 +thread2 ruby1.8 CALL nanosleep(0x28b68eb0,0) +thread0 ruby1.8 CALL write(0x2,0xbfbf98a0,0x3d) +thread0 ruby1.8 GIO fd 2 wrote 61 bytes + +(2012-02-08 patchlevel 358) [i486-kfreebsd-gnu] + + +thread0 ruby1.8 RET write 61/0x3d +thread0 ruby1.8 CALL sigprocmask(SIG_UNBLOCK,0xbfbfbf50,0) thread0 ruby1.8 RET sigprocmask 0 -thread2 ruby1.8 CALL sigprocmask(SIG_SETMASK,0x28b68e80,0) -thread0 ruby1.8 CALL sigsuspend(0xbfbfdc4c) -thread2 ruby1.8 RET sigprocmask 0 -thread2 ruby1.8 CALL thr_kill(thread0,SIG(null)) -thread2 ruby1.8 RET thr_kill 0 -thread0 ruby1.8 PSIG SIG(null) caught handler=0x28188860 mask=0x8000 code=0x10001 -thread2 ruby1.8 CALL thr_kill(thread1,SIG(null)) -thread0 ruby1.8 RET sigsuspend JUSTRETURN -thread2 ruby1.8 RET thr_kill 0 -thread0 ruby1.8 CALL sigreturn(0xbfbfd930) +thread0 ruby1.8 CALL thr_kill(thread0,SIGIOT) +thread0 ruby1.8 RET thr_kill 0 +thread0 ruby1.8 PSIG SIGIOT SIG_DFL code=0x10001 thread1 ruby1.8 RET poll -1 errno 4 Interrupted system call -thread0 ruby1.8 RET sigreturn JUSTRETURN -thread1 ruby1.8 PSIG SIG(null) caught handler=0x28188710 mask=0xfffefeef code=0x10001 -thread2 ruby1.8 CALL thr_exit(0x807c1c0) -thread0 ruby1.8 CALL write(0x4,0xbfbfdc8c,0x24) -thread1 ruby1.8 CALL sigreturn(0x807a850) -thread0 ruby1.8 GIO fd 4 wrote 36 bytes - 0x a01a 3328 0100 0204 44a1 0e00 0060 0828 bc2a 1828 70fd 1628 d0d5 1728 e0dc
Bug#673704: libfprint: FTBFS on kfreebsd due to missing ETIME
Source: libfprint Version: 20110418git-2 Severity: normal Tags: upstream, help -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, according to past build logs, libfprint fails to build from source on kfreebsd-* with the following error: drivers/uru4000.c: In function 'rebootpwr_run_state': drivers/uru4000.c:804:31: error: 'ETIME' undeclared (first use in this function) drivers/uru4000.c:804:31: note: each undeclared identifier is reported only once for each function it appears in See https://buildd.debian.org/status/logs.php?pkg=libfprint for other logs. Help welcome. Cheers, OdyX -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQGcBAEBCAAGBQJPuVdxAAoJEIvPpx7KFjRV6OUL/1j4dE99hbAu78yYN5G/f/JX rDppIKl+N0ObexAO96enrLg+Qusqytm2IhuKKx+eQl/wJSeJTcLe/a69tXEpMlXR 8OM6cp4eE0ZAVhvmnV6vJbQaE/2ET2j3+MgjAPldsJFWXUmyC2Z2RCDaoW6l6GHs 2J4HPxFaFta4+0lc6m/iTBBnQIQVzMMwx8Pf19vPLJos6aIN0tmxSOz5RpVBKPw4 roUZfL/tERNRNomS1M80dYbIEcVA5hVMcGmLBQ7reXtdCJ0eYo+uoJ7tCIp5PGlj oIRauGVQdRGfnPLZwcgnTxHtbVpCTCzVCgdnhstLs0ReR0ghVeyibcKJ2shcFOAd umNbzeSXztsMrowxNmc1h+x6Ic6OthWxi0V85wF5myRDnvwj1/rDEO2PqW6L+yfl L9U2QvEZ+TFRoauNu/tFIG2n709e9rdUJc6KlW+XKqGNrX9GvlMurpGmo10xy/VX QoPa5CVSNuuw9r+KcAPDOWzEhwmvVlTv/AyKw5jfHw== =u88c -END PGP SIGNATURE- -- 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/20120520204330.14564.69214.reportbug@Tamino
Bug#673711: kfreebsd-9: pthread_cond_timedwait returns immediately with ETIMEDOUT
Package: kfreebsd-image-9.0-1-amd64
Version: 9.0-3
Severity: important
File: kfreebsd-9
Tags: upstream
Hi,
when using pthread_cond_timedwait, it often returns immediately with
the error ETIMEDOUT regardless to the length of the timeout passed to the
function. I have provided a C program that illustrates the problem.
It affects the upstream version (obtained by kfreebsd-downloader).
I have found a thread that, I believe, discusses about the issue:
http://freebsd.1045724.n5.nabble.com/pthread-cond-timedwait-broken-in-9-stable-from-JAN-10-td5487565.html
I would normally not report the bug since it seems already reported
upstream. However, I stumbled into this problem while I was trying to fix an
RC-bug (#673681) and according to the linked thread, there might be a small
patch that could fix the issue.
Thanks for considering the problem,
Cheers
Nicolas Bourdaud
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 9.0-RELEASE
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages kfreebsd-image-9.0-1-amd64 depends on:
ii devd 9.0+ds1-4
ii freebsd-utils 9.0+ds1-4
ii kbdcontrol 9.0+ds1-4
ii kldutils 9.0+ds1-4
kfreebsd-image-9.0-1-amd64 recommends no packages.
kfreebsd-image-9.0-1-amd64 suggests no packages.
-- no debconf information
#include stdio.h
#include pthread.h
#include errno.h
#include time.h
#include stdlib.h
#define DELTA 4 //400ms
#define NS_PER_MS 100
#define NS_PER_SEC 10
void addtime(struct timespec* res, struct timespec* ref, long delta)
{
res-tv_sec = ref-tv_sec;
res-tv_nsec = ref-tv_nsec + delta;
if (res-tv_nsec = NS_PER_SEC) {
res-tv_nsec -= NS_PER_SEC;
res-tv_sec++;
}
}
int main(void)
{
int i;
struct timespec ts, to;
pthread_mutex_t lock;
pthread_cond_t cond;
pthread_mutex_init(lock, NULL);
pthread_cond_init(cond, NULL);
for (i=0; i10; i++) {
clock_gettime(CLOCK_REALTIME, ts);
printf(start: sec:%li msec:%li\n, (long)ts.tv_sec, ts.tv_nsec/NS_PER_MS);
addtime(to, ts, DELTA);
pthread_mutex_lock(lock);
while (pthread_cond_timedwait(cond, lock, to) != ETIMEDOUT);
pthread_mutex_unlock(lock);
clock_gettime(CLOCK_REALTIME, ts);
printf(end: sec:%li msec:%li\n, (long)ts.tv_sec, ts.tv_nsec/NS_PER_MS);
}
pthread_mutex_destroy(lock);
pthread_cond_destroy(cond);
return EXIT_SUCCESS;
}
Bug#673711: kfreebsd-9: pthread_cond_timedwait returns immediately with ETIMEDOUT
Hi! Nicolas Bourdaud nicolas.bourd...@gmail.com writes: when using pthread_cond_timedwait, it often returns immediately with the error ETIMEDOUT regardless to the length of the timeout passed to the function. I have provided a C program that illustrates the problem. It affects the upstream version (obtained by kfreebsd-downloader). I have found a thread that, I believe, discusses about the issue: http://freebsd.1045724.n5.nabble.com/pthread-cond-timedwait-broken-in-9-stable-from-JAN-10-td5487565.html I would normally not report the bug since it seems already reported upstream. However, I stumbled into this problem while I was trying to fix an RC-bug (#673681) and according to the linked thread, there might be a small patch that could fix the issue. Thanks for your bug report! I'm a bit skeptical hoqwever that this build failure is caused by a kernel bug in kfreebsd-9 ad the buildds (where this build failure happens) are running an 8.1 kernel which (according to the linked thread) is not affected. However there was (IIRC) indeed some change in pthread/libc code recently that might cause this issue. Regards Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer -- 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/87bolilawo@hepworth.siccegge.de
Re: Bug#673711: pthread_cond_timedwait returns immediately with ETIMEDOUT
reassign 673711 libc0.1 retitle 673711 pthread_cond_timedwait returns immediately with ETIMEDOUT found 673711 eglibc/2.13-32 tags 673711 - upstream user debian-bsd@lists.debian.org usertags 673711 kfreebsd thanks Hi! On 20/05/12 23:56, Christoph Egger wrote: Nicolas Bourdaud nicolas.bourd...@gmail.com writes: http://freebsd.1045724.n5.nabble.com/pthread-cond-timedwait-broken-in-9-stable-from-JAN-10-td5487565.html I know the symptoms are similar, but that sounded like a recent kernel bug/change making the timers unreliable. Whereas this seems more like a familiar problem in GNU/kFreeBSD's glibc. I'm a bit skeptical hoqwever that this build failure is caused by a kernel bug in kfreebsd-9 ad the buildds (where this build failure happens) are running an 8.1 kernel which (according to the linked thread) is not affected. Indeed, I tried Nicolas' testcase (thanks for that) which showed issues on kfreebsd-i386 8.3-1-686 8.3-2, kfreebsd 9.0-1-amd64 9.0-3; and of course this was an issue for the kfreebsd-* buildds which run 8.1 kernels. However there was (IIRC) indeed some change in pthread/libc code recently that might cause this issue. Robert's librt/pthread patches went into eglibc 2.13-32 to try fix this kind of problem, but a few packages are still showing problems like this. Perl, ruby1.8, ruby1.9.1, and the Python-based waf builder a few packages use (like guitarix), all have issues kinda similar to this. I find it interesting that this bug led to those glibc errors (double free or corruption) in #673681 instead of a hang or simple test failure. 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/4fb97c77.2080...@pyro.eu.org
Processed: Re: Bug#673711: pthread_cond_timedwait returns immediately with ETIMEDOUT
Processing commands for cont...@bugs.debian.org: reassign 673711 libc0.1 Bug #673711 [kfreebsd-image-9.0-1-amd64] kfreebsd-9: pthread_cond_timedwait returns immediately with ETIMEDOUT Bug reassigned from package 'kfreebsd-image-9.0-1-amd64' to 'libc0.1'. No longer marked as found in versions kfreebsd-9/9.0-3. Ignoring request to alter fixed versions of bug #673711 to the same values previously set retitle 673711 pthread_cond_timedwait returns immediately with ETIMEDOUT Bug #673711 [libc0.1] kfreebsd-9: pthread_cond_timedwait returns immediately with ETIMEDOUT Changed Bug title to 'pthread_cond_timedwait returns immediately with ETIMEDOUT' from 'kfreebsd-9: pthread_cond_timedwait returns immediately with ETIMEDOUT' found 673711 eglibc/2.13-32 Bug #673711 [libc0.1] pthread_cond_timedwait returns immediately with ETIMEDOUT Marked as found in versions eglibc/2.13-32. tags 673711 - upstream Bug #673711 [libc0.1] pthread_cond_timedwait returns immediately with ETIMEDOUT Removed tag(s) upstream. user debian-bsd@lists.debian.org Setting user to debian-bsd@lists.debian.org (was ste...@pyro.eu.org). usertags 673711 kfreebsd Bug#673711: pthread_cond_timedwait returns immediately with ETIMEDOUT There were no usertags set. Usertags are now: kfreebsd. thanks Stopping processing here. Please contact me if you need assistance. -- 673711: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673711 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.133755610423558.transcr...@bugs.debian.org
Re: Bug#673711: pthread_cond_timedwait returns immediately with ETIMEDOUT
Hi On 21/05/2012 01:21, Steven Chamberlain wrote: I find it interesting that this bug led to those glibc errors (double free or corruption) in #673681 instead of a hang or simple test failure. Actually this bug does not cause the corruption in #673681: a race condition in the unit tests is the cause. It was only after having fixed the race condition that this bug revealed. Cheers, Nicolas signature.asc Description: OpenPGP digital signature
