Bug#713035: FTBFS on amd64/ia64 testsuite fails
Hello, Ketvirtadienis 27 Birželis 2013 14:37:17 rašė: On Thu, Jun 27, 2013 at 08:05:17PM +0200, Aurelien Jarno wrote: The problem is that the amd64 and ia64 build daemons which tried to build this version of eglibc are all using eatmydata. eatmydata do not correctly simulate fsync, msync and fdatasync as cancellation points. It should be possible fixing that by calling pthread_testcancel() from eatmydata, though I haven't tried that yet. It seems pretty testsuite-hostile to wrap builds in any LD_PRELOAD, as you have no idea if the thing(s) the testsuites might be checking are now invalidated by said preload. Was there actually a sane rationale put forward for this buildd change? I can see the argument for wanting the apt/dpkg bits wrapped, but doing so for the build itself just seems like asking for trouble, with very little potential gain. Speaking with my maintainer hat on, when I first came upon eatmydata, I thought: it will be a huge time saviour for personal and maybe debian buildds. My primary idea was to wrap apt/dpkg with eatmydata since they use fsync() and friends *really* extensively. Too bad fsync() used to be (still is?) very slow on btrfs filesystem. For exactly this purpose eatmydata script supports symlink mode (see eatmydata(1)). Doing: # ln -s /usr/bin/eatmydata /usr/local/bin/apt-get # ln -s /usr/bin/eatmydata /usr/local/bin/dpkg in the buildd environment should be enough to wrap only these tools without too much hassle (i.e. sbuild configuration changes). I'm not sure how I feel about wrapping the whole build. Maybe it's not such a bad idea after all if somebody tested that it speeded things up much more significantly. However, I just wanted to let you know that a more conservative approach is possible. P.S. I'm aware that upstream released a new upstream release with the fix for this bug. However, packaging it might take some time due to significant buildsystem changes and other stuff. However, hopefully, I will get it eventually done in a few weeks. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#561203: FTBFS [hppa] - pthread_create() (QThread) + fork() = crash
tags 561203 pending thanks Hello, On antradienis 22 Gruodis 2009 21:54:16 Modestas Vainius wrote: when investigating this issue further, I determined that fork() following pthread_create() sometimes makes the application crash. In order to reproduce, build attached minifail.cpp with: [.. snip ..] When repeatedly running it as `minifail` (pure_test() mode), I get: $ i=0; while true; do i=$(($i+1)); echo Run $i; ./minifail; done; [.. snip ..] The hang which is original problem of this FTBFS, can be reproduced with `./minifail qt` (qt_test() mode that uses QThread + fork()). QThread internally uses pthreads but unfortunately I was not able to reproduce the hang with pure pthread_* calls. $ i=0; while true; do i=$(($i+1)); echo Run $i; ./minifail qt; done; [.. snip ..] ii libc6 2.10.2-2 GNU C Library: Shared libraries It seems libc6 2.10.2-3 fixed the problem. I cannot reproduce the bug with both test cases above any more. As far as I can tell from the changelog, rebuild with gcc-4.4 helped. I will close this bug once a couple of KDE packages get built on hppa successfully. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#561203: FTBFS [hppa] - pthread_create() (QThread) + fork() = crash
tags 561203 - pending thanks Hello, On pirmadienis 04 Sausis 2010 17:18:40 Helge Deller wrote: libc6-2.10.2-3 made it much, *much* better (I'm not sure yet why!!). But I can still reproduce the bug on my system with your testcases. It's just much harder to reproduce it, but it still happens. So, it's not fixed yet, it just happens much less often. Indeed, you are right. I was able to run `./minifail qt` 90k times without a hang, but it hang at the 3000+th run next time. Anyway, probability of hitting this bug has become much much lower now so maybe KDE will finally build on hppa now. Even if build fails with a timeout like previously, it should be enough to give back it once again. Btw, backtrace of the hang is different now: (gdb) t 2 [Switching to thread 2 (Thread 0x41d26480 (LWP 4088))]#0 0x046c in ?? () (gdb) bt #0 0x046c in ?? () #1 0x40a06380 in ?? () from /lib/libc.so.6 #2 0x40a06380 in ?? () from /lib/libc.so.6 #3 0x40a060b4 in malloc () from /lib/libc.so.6 #4 0x4093b2b4 in operator new(unsigned int) () from /usr/lib/libstdc++.so.6 #5 0x404e45e8 in QThreadPrivate::createEventDispatcher (data=0x16c40) at thread/qthread_unix.cpp:159 #6 0x404e4858 in QThreadPrivate::start (arg=0x168f8) at thread/qthread_unix.cpp:183 #7 0x403080a0 in start_thread () from /lib/libpthread.so.0 #8 0x40a66898 in clone () from /lib/libc.so.6 #9 0x04010300 in ?? () #10 0x04010300 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) x/20i 0x40a060b4 0x40a060b4 malloc+1208: b,l 0x40a05d60 malloc+356,r0 0x40a060b8 malloc+1212: copy ret0,r5 0x40a060bc malloc+1216: mfctl tr3,ret0 0x40a060c0 malloc+1220: ldi 0,r23 0x40a060c4 malloc+1224: ldw -478(ret0),r25 0x40a060c8 malloc+1228: ldi 1,r24 0x40a060cc malloc+1232: depwi -1,31,1,r25 0x40a060d0 malloc+1236: copy r3,r26 0x40a060d4 malloc+1240: copy r19,r4 0x40a060d8 malloc+1244: be,l 100(sr2,r0),sr0,r31 0x40a060dc malloc+1248: ldi d2,r20 0x40a060e0 malloc+1252: copy r4,r19 0x40a060e4 malloc+1256: b,l 0x40a05d28 malloc+300,r0 0x40a060e8 malloc+1260: ldo -8(r5),r20 0x40a060ec malloc+1264: mfctl tr3,ret0 0x40a060f0 malloc+1268: ldi 0,r23 0x40a060f4 malloc+1272: ldw -478(ret0),r25 0x40a060f8 malloc+1276: ldi 1,r24 0x40a060fc malloc+1280: depwi -1,31,1,r25 0x40a06100 malloc+1284: copy r7,r26 (gdb) x/20i 0x40a06380 0x40a06380: b,l 0x40a0622c,r0 0x40a06384: copy r4,r19 0x40a06388: mfctl tr3,ret0 0x40a0638c: copy r5,r26 0x40a06390: ldw -478(ret0),r25 0x40a06394: ldi 0,r23 0x40a06398: depwi -1,31,1,r25 0x40a0639c: ldi 1,r24 0x40a063a0: copy r19,r4 0x40a063a4: be,l 100(sr2,r0),sr0,r31 0x40a063a8: ldi d2,r20 0x40a063ac: copy r4,r19 0x40a063b0: b,l,n 0x40a06290,r0 0x40a063b4: stw rp,-14(sp) 0x40a063b8: addil L%1000,r19,r1 0x40a063bc: ldo 40(sp),sp 0x40a063c0: ldw 35c(r1),ret0 0x40a063c4: stw r4,-34(sp) 0x40a063c8: copy r19,r4 0x40a063cc: stw r19,-20(sp) -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Re: Proposal(s) for handling libqt3-mt situation
Hi, 2008 m. February 16 d., Saturday, Pierre Habouzit rašė: Okay that's quite a few, so the Conflict option sucks. Here is another plan, tell me what you think, we put a debian specific hack in the glibc to reenable the extern inlines for _ONLY_ the packages that ask for it, for lenny, and remove it in lenny+1. Ok, so it's actually a debate whether to readd missing symbols to affected libraries themselves or to libc6-dev. If Matthew is correct, all packages except trustedqsl are victims of libqt3-mt. By the way, I'm not sure if tsql is a problem (atoi is versioned?): $ objdump -tT /usr/bin/tqsl | grep atoi DF *UND* 0015 GLIBC_2.2.5 atoi $ objdump -tT /usr/bin/tqslcert | grep atoi DF *UND* 0015 GLIBC_2.2.5 atoi $ objdump -Tt /usr/lib/libtqsllib.so.1.0.0 | grep atoi DF *UND* 0015 GLIBC_2.2.5 atoi Qt _has_ to use it to build, though digikam and friends won't, so that they will _stop_ using the damn symbols. This way partial upgrades to lenny works, and in lenny+1 the symbols just disappear for good. Sorry, but that's wrong. It's true that Qt gets those symbols at compile time, but any binaries linking against Qt references [fl]?stat64 from Qt at link time. Hence as long any application using [fl]?stat64 are linked against Qt3 with [fl]?stat64 exported (and that has nothing to do with headers), it will depend on [fl]?stat64 being present. If what you say was true, ktorrent 2.2.5.dfsg.1-1 should not depend on fstat64, because 1. ktorrent 2.2.5.dfsg.1-1 was uploaded on Wed, 06 Feb 2008 23:07:08 +0200, hence built against libc6-dev (= 2.7) without extern inlines in sys/stat.h That's essentially the same as it would be building without -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK 2. qt-x11-free 3.3.7-9 was uploaded on Wed, 26 Sep 2007 21:42:24 +0200, hence built against libc6-dev ( 2.7) with extern inlines in sys/stat.h present. That's essentially the same as it would be building with -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK 3. ktorrent 2.2.5.dfsg.1-1 was linked against qt-x11-free 3.3.7-9 (app, not using -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK, was linked against lib, using -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK). As you see, all conditions were met, but, unfortunately, ktorrent 2.2.5.dfsg.1-1 still depends on exported fstat64 No Conflicts are needed, We only need a list of _library_ packages that have the stat (and other symbols) defined reuploaded with a -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK in the CFLAGS. Do you want to add hack to lib6-dev just for Qt3? Then a binNMU campaign of the broken _packages_ has to follow (digikam, k3b, ... ) so that they loose their wrong *UND* symbols for good. Unless libqt3-mt loses them, binNMUs won't help. P.S. However, we might want to delay libqt3-mt transition (by adding back [fl]?stat64 symbols one way or another and forgetting it) to lenny+1, because it's very likely that there will have been fewer applications using it by then. -- Modestas Vainius [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part.
