Bug#575534: libc6: periodic timers hang fork()
On Sat, May 15, 2010 at 10:29:13PM +0200, Joachim Breitner wrote:
> 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 don't think it is possible to disable the timers while running clone
in the libc side. POSIX 2008 is explicit about how signals should be
delivered, and doing that would create a small window of time that
violates POSIX 2008.
I guess the kernel behaviour of restarting the clone syscall in that
case is also to not violate POSIX 2008.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: