Hi Aruelien, Am Samstag, den 15.05.2010, 12:28 +0200 schrieb Aurelien Jarno: > On Fri, May 14, 2010 at 10:38:17PM +0200, Joachim Breitner wrote: > > I’d like to follow up on this issue. According to the libc bug reporting > > guidelines, one should hear from the Debian maintainers whether the bug > > could possibly be Debian-specific before reporting them upstream. Can > > you comment on that? > > > > The bug might look like it is a weird corner case, but it causes serious > > trouble with building large haskell packages on some arches, and thus > > the transition of such packages to testing. > > > > I am not sure it is GNU libc bug, and I am not sure there is an > acceptable solution. The timer interrupts the clone syscall itself, so > everything happens in the kernel. > > Maybe stopping the timer before the clone syscall and restoring it > after is something acceptable? I’m by far not an expert in these areas, but seeing the same problem happen with different uses (profiling a C binary, running Haskell code) seems that the problem is either in the shared code (the libc), or in the usage of it. In the example C code with profiling, if the bug is not a libc bug, then it is a bug in the compiler generating the profiling code? Or should it be libc’s responsibility to disable timers while running clone? Is that even possible? Would this cause other problems? I created a ticket against ghc, the haskell compiler, and asked if they think they should and can disable the timer as well: Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part