Debian Bug report logs - #575534
libc6: periodic timers hang fork()

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Tomas Janousek <tomi@nomi.cz>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libc6: periodic timers hang fork()

Date: Fri, 26 Mar 2010 17:14:04 +0100

Package: libc6
Version: 2.10.2-6
Severity: normal

Whenever a program uses some kind of periodic timer (profiling, Haskell
thread scheduler, ...) and makes a fork call that takes more time than the
timer's interval, it enters and endless loop of clone syscalls being
interrupted by the signal:

17:08:49.362528 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb765f938) = ? ERESTARTNOINTR (To be restarted) <0.031840>
17:08:49.394551 --- SIGPROF (Profiling timer expired) @ 0 (0) ---
17:08:49.394693 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb765f938) = ? ERESTARTNOINTR (To be restarted) <0.031548>
17:08:49.426335 --- SIGPROF (Profiling timer expired) @ 0 (0) ---
17:08:49.426475 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb765f938) = ? ERESTARTNOINTR (To be restarted) <0.031768>
17:08:49.458339 --- SIGPROF (Profiling timer expired) @ 0 (0) ---
[... and so on ...]

On my hardware, this happens for programs using more than 400 megs of memory
(there's a linear dependence between memory used and the duration of clone).
That means that any program that uses more than 400 megs of memory can't use
fork and be profiled at the same time.

A reproducer is at <http://store.lisk.in/tmp/perm/fork_profiling_hang.tar.gz>.
`make all' generates a graph of the said dependence and `make hang' launches a
test case that consumes 500 megs of memory and forks then. If that's not
enough, just raise the number in the Makefile.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (990, 'stable'), (500, 'unstable'), (500, 'stable'), (200, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.32.7-lis-00002-gd18ac29 (SMP w/2 CPU cores)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6 depends on:
ii  libc-bin                      2.10.2-6   Embedded GNU C Library: Binaries
ii  libgcc1                       1:4.4.1-4  GCC support library

Versions of packages libc6 recommends:
ii  libc6-i686                    2.10.2-6   GNU C Library: Shared libraries [i

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]         1.5.27     Debian configuration management sy
ii  glibc-doc                     2.10.2-6   Embedded GNU C Library: Documentat
ii  locales                       2.10.2-6   Embedded GNU C Library: National L

-- debconf information:
* glibc/upgrade: true
  glibc/disable-screensaver:
  glibc/restart-failed:
* glibc/restart-services:

-- 
Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/

Message #10 received at 575534@bugs.debian.org (full text, mbox, reply):

From: Joachim Breitner <nomeata@debian.org>

To: Stepan Golosunov <stepan@golosunov.pp.ru>

Cc: debian-release@lists.debian.org, debian-haskell@lists.debian.org, hppa@buildd.debian.org, 575534@bugs.debian.org

Subject: Re: hppa and haskell packages

Date: Sun, 28 Mar 2010 00:02:36 +0100

[Message part 1 (text/plain, inline)]

affects 575534 ghc6
thanks

Hi,

Am Samstag, den 27.03.2010, 23:47 +0400 schrieb Stepan Golosunov:
> 24.03.2010 в 13:24:53 -0600 dann frazier написал:
> > I started an agda build on paer 8 days ago - it is still running. Memory
> > does not appear to be an issue (swap is available, but unused). Throwing
> > more CPU at it might improve things - but I don't think a CPU exists with
> > enough cycles to make it build in any reasonable amount of time.
> > 
> > strace of the ghc6 process shows an infinite loop of:
> > 
> > rt_sigreturn()                          = -14059
> > clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002b28) = -513
> > --- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
> > rt_sigreturn()                          = -14059
> > clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002b28) = -513
> > --- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
> ...
> 
> > I don't think the hardware is the issue here - this has got to be a
> > bug somewhere.
> 
> Looks like this was reported as
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575534

thanks for spotting this. Maybe all the problems building on slower arch
are just this one bug. I’ll add an "affects ghc6" as a reminder that
this bug affects the Haskell packages in general.

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

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 575534@bugs.debian.org (full text, mbox, reply):

From: Joachim Breitner <nomeata@debian.org>

To: 575534@bugs.debian.org

Subject: Re: libc6: periodic timers hang fork()

Date: Fri, 14 May 2010 22:38:17 +0200

[Message part 1 (text/plain, inline)]

Hi,

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.

Thanks,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

[signature.asc (application/pgp-signature, inline)]

Message #22 received at 575534@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Joachim Breitner <nomeata@debian.org>, 575534@bugs.debian.org

Subject: Re: Bug#575534: libc6: periodic timers hang fork()

Date: Sat, 15 May 2010 12:28:52 +0200

On Fri, May 14, 2010 at 10:38:17PM +0200, Joachim Breitner wrote:
> Hi,
> 
> 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?

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Message #27 received at 575534@bugs.debian.org (full text, mbox, reply):

From: Joachim Breitner <nomeata@debian.org>

To: Aurelien Jarno <aurelien@aurel32.net>

Cc: 575534@bugs.debian.org

Subject: Re: Bug#575534: libc6: periodic timers hang fork()

Date: Sat, 15 May 2010 22:29:13 +0200

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 575534@bugs.debian.org (full text, mbox, reply):

From: "GHC" <cvs-ghc@haskell.org>

Cc: glasgow-haskell-bugs@haskell.org

Subject: [GHC] #4074: Forking not possible with large processes

Date: Sat, 15 May 2010 20:28:43 -0000

#4074: Forking not possible with large processes
---------------------------------+------------------------------------------
    Reporter:  nomeata           |       Owner:              
        Type:  bug               |      Status:  new         
    Priority:  normal            |   Component:  Compiler    
     Version:  6.12.1            |    Keywords:              
          Os:  Linux             |    Testcase:              
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
---------------------------------+------------------------------------------
 If a haskell program requires a lot of memory, trying to fork() fails
 because, due to the program size, the clone() syscall takes long and will
 interrupted by the ghc runtime timer, restarting the syscall, just to be
 interrupted again.

 This happens repeatedly with ghc 6.12, which seems to require  noticeable
 more memory than 6.10, when building large Haskell programs on slower
 arches, and causes some problems with Haskell in Debian.

 The problem can also be observed by running a simple C program that
 malloc’s a lot of memory (in the range of 1G) and then tries to fork with
 profiling enabled.

 In the corresponding Debian bug report against libc
 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575534), which also has
 the demo C code, it was suggested that it might be the program’s
 responsibility to disable such timers while clone() runs.

 Do you agree with that? Is it something you can do? Might this be related
 to #1882 (which mentions timers and fork)?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4074>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

Message #33 received at 575534@bugs.debian.org (full text, mbox, reply):

From: "GHC" <cvs-ghc@haskell.org>

Cc: glasgow-haskell-bugs@haskell.org

Subject: Re: [GHC] #4074: Forking not possible with large processes

Date: Mon, 17 May 2010 08:37:19 -0000

#4074: Forking not possible with large processes
---------------------------------+------------------------------------------
    Reporter:  nomeata           |        Owner:  simonmar               
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:  6.12.3                 
   Component:  Runtime System    |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:  Easy (less than 1 hour)
          Os:  Linux             |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown           
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar
  * difficulty:  => Easy (less than 1 hour)
  * component:  Compiler => Runtime System
  * milestone:  => 6.12.3


Comment:

 I think we probably should disable timers in `forkProcess`; I'll look into
 it.

 Incedentally, this timer/fork issue is the reason that #3998 is hard to
 fix.  The workaround we use in the process library is to use `vfork`
 instead of `fork`.  (#1882 is unrelated, I think)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4074#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

Message #36 received at 575534@bugs.debian.org (full text, mbox, reply):

From: "GHC" <cvs-ghc@haskell.org>

Cc: glasgow-haskell-bugs@haskell.org

Subject: Re: [GHC] #4074: Forking not possible with large processes

Date: Mon, 17 May 2010 09:21:44 -0000

#4074: Forking not possible with large processes
---------------------------------+------------------------------------------
    Reporter:  nomeata           |        Owner:  simonmar               
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:  6.12.3                 
   Component:  Runtime System    |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:  Easy (less than 1 hour)
          Os:  Linux             |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown           
---------------------------------+------------------------------------------

Comment(by simonmar):

 I'm having trouble constructing a test case in Haskell that displays the
 problem.  Can anyone else do this?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4074#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

Message #39 received at 575534@bugs.debian.org (full text, mbox, reply):

From: "GHC" <cvs-ghc@haskell.org>

Cc: glasgow-haskell-bugs@haskell.org

Subject: Re: [GHC] #4074: Forking not possible with large processes

Date: Mon, 17 May 2010 14:55:05 -0000

#4074: Forking not possible with large processes
---------------------------------+------------------------------------------
    Reporter:  nomeata           |        Owner:  simonmar               
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:  6.12.3                 
   Component:  Runtime System    |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:  Easy (less than 1 hour)
          Os:  Linux             |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown           
---------------------------------+------------------------------------------

Comment(by nomeata):

 It is probably hard to find a machine that is both slow enough (CPU wise)
 and large enough (memory wise). Here is my test code:

 {{{
 import qualified Data.ByteString as BS
 import Control.Concurrent
 import System.Process

 main = do
     let size = 1000 * 1024 * 1024
         bs = BS.replicate size (fromIntegral 5)
     BS.minimum bs `seq` return ()
     forkIO $ putStrLn "Forked Child"
     runCommand "echo hi"
     putStrLn "Parent"
     BS.minimum bs `seq` return ()
 }}}

 On my computer, I could trigger the behaviour with a size of
 1500*1024*1024:
 {{{
 vfork()                                 = ? ERESTARTNOINTR (To be
 restarted)
 --- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
 rt_sigreturn(0x1a)                      = 56
 clone(child_stack=0xbea,
 flags=CLONE_FILES|CLONE_PTRACE|CLONE_VFORK|CLONE_DETACHED|126) = ?
 ERESTARTNOINTR (To be restarted)
 --- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
 rt_sigreturn(0x1a)                      = 56
 [..]
 }}}

 What is interesting is that the program uses vfork() at first. If this
 works (because no timer interrupt happens), this call is used:

 {{{
 vfork(Process 3243 attached
 )                                 = 3243
 }}}

 So there seems to be a fallback logic that tries clone() if vfork() does
 not work which kicks in even in the case of ERESTARTNOINTR – probably not
 what was intended. But I guess this is independent of our issue.

 If you have problem reproducing the error, you can see if at strace at
 least shows one or two failed calls due to ERESTARTNOINTR. If so, the
 problem is present, the symptoms are just not as bad.

 I could not observe this problem with the threaded RTS right now.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4074#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

Message #42 received at 575534@bugs.debian.org (full text, mbox, reply):

From: "GHC" <cvs-ghc@haskell.org>

Cc: glasgow-haskell-bugs@haskell.org

Subject: Re: [GHC] #4074: Forking not possible with large processes

Date: Tue, 18 May 2010 13:48:01 -0000

#4074: Forking not possible with large processes
---------------------------------+------------------------------------------
    Reporter:  nomeata           |        Owner:  simonmar               
        Type:  bug               |       Status:  infoneeded             
    Priority:  normal            |    Milestone:  6.12.3                 
   Component:  Runtime System    |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:  Easy (less than 1 hour)
          Os:  Linux             |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown           
---------------------------------+------------------------------------------
Changes (by simonmar):

  * status:  new => infoneeded


Comment:

 I'm not able to reproduce it, but I've applied the following fix anyway:

 {{{
 Tue May 18 04:32:14 PDT 2010  Simon Marlow <marlowsd@gmail.com>
   * Fix #4074 (I hope).

   1. allow multiple threads to call startTimer()/stopTimer() pairs
   2. disable the timer around fork() in forkProcess()

   A corresponding change to the process package is required.
 }}}

 and the process package patch:

 {{{
 Tue May 18 09:36:17 BST 2010  Simon Marlow <marlowsd@gmail.com>
   * Fix #4074: disable the timer signal around fork()
 }}}

 If you can test the fix that would be very helpful.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4074#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

Message #45 received at 575534@bugs.debian.org (full text, mbox, reply):

From: "GHC" <cvs-ghc@haskell.org>

Cc: glasgow-haskell-bugs@haskell.org

Subject: Re: [GHC] #4074: Forking not possible with large processes

Date: Tue, 18 May 2010 13:48:12 -0000

#4074: Forking not possible with large processes
---------------------------------+------------------------------------------
    Reporter:  nomeata           |        Owner:  simonmar               
        Type:  bug               |       Status:  merge                  
    Priority:  normal            |    Milestone:  6.12.3                 
   Component:  Runtime System    |      Version:  6.12.1                 
    Keywords:                    |   Difficulty:  Easy (less than 1 hour)
          Os:  Linux             |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown           
---------------------------------+------------------------------------------
Changes (by simonmar):

  * status:  infoneeded => merge


-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4074#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

Message #50 received at 575534@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Joachim Breitner <nomeata@debian.org>, 575534@bugs.debian.org

Subject: Re: Bug#575534: libc6: periodic timers hang fork()

Date: Wed, 19 May 2010 20:47:04 +0200

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

Message #53 received at 575534@bugs.debian.org (full text, mbox, reply):

From: "GHC" <cvs-ghc@haskell.org>

Cc: glasgow-haskell-bugs@haskell.org

Subject: Re: [GHC] #4074: Forking not possible with large processes

Date: Wed, 19 May 2010 21:44:04 -0000

#4074: Forking not possible with large processes
--------------------------------------+-------------------------------------
  Reporter:  nomeata                  |          Owner:  simonmar        
      Type:  bug                      |         Status:  closed          
  Priority:  normal                   |      Milestone:  6.12.3          
 Component:  Runtime System           |        Version:  6.12.1          
Resolution:  fixed                    |       Keywords:                  
Difficulty:  Easy (less than 1 hour)  |             Os:  Linux           
  Testcase:                           |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown             |  
--------------------------------------+-------------------------------------
Changes (by igloo):

  * status:  merge => closed
  * resolution:  => fixed


Comment:

 Both merged.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4074#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

Message #56 received at 575534@bugs.debian.org (full text, mbox, reply):

From: "GHC" <cvs-ghc@haskell.org>

Cc: glasgow-haskell-bugs@haskell.org

Subject: Re: [GHC] #4074: Forking not possible with large processes

Date: Thu, 20 May 2010 10:16:00 -0000

#4074: Forking not possible with large processes
--------------------------------------+-------------------------------------
  Reporter:  nomeata                  |          Owner:  simonmar        
      Type:  bug                      |         Status:  closed          
  Priority:  normal                   |      Milestone:  6.12.3          
 Component:  Runtime System           |        Version:  6.12.1          
Resolution:  fixed                    |       Keywords:                  
Difficulty:  Easy (less than 1 hour)  |             Os:  Linux           
  Testcase:                           |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown             |  
--------------------------------------+-------------------------------------

Comment(by nomeata):

 So far, I avoided having to build ghc6, therefore I’m reluctant to do it
 now. Maybe when I find some spare time for it. But I’m optimistic that
 this fixes the problem.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4074#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

Message #61 received at 575534@bugs.debian.org (full text, mbox, reply):

From: Joachim Breitner <nomeata@debian.org>

To: Aurelien Jarno <aurelien@aurel32.net>

Cc: 575534@bugs.debian.org, Tomas Janousek <tomi@nomi.cz>

Subject: Re: Bug#575534: libc6: periodic timers hang fork()

Date: Thu, 20 May 2010 12:17:51 +0200

[Message part 1 (text/plain, inline)]

Hi,

Am Mittwoch, den 19.05.2010, 20:47 +0200 schrieb Aurelien Jarno:
> 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.

the ghc compiler was now patched to disable the timers around
fork()/clone(). I did not yet test whether this fixed the problems we
observe on the buildds.

Thomas, in your case, I guess the bug needs to be reassigned against
gcc, as it might be an error in the profiling code created by gcc.

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

[signature.asc (application/pgp-signature, inline)]

Message #66 received at 575534@bugs.debian.org (full text, mbox, reply):

From: Tomas Janousek <tomi@nomi.cz>

To: Joachim Breitner <nomeata@debian.org>, 575534@bugs.debian.org

Cc: Aurelien Jarno <aurelien@aurel32.net>

Subject: Re: Bug#575534: libc6: periodic timers hang fork()

Date: Thu, 20 May 2010 12:40:41 +0200

Hello,

On Thu, May 20, 2010 at 12:17:51PM +0200, Joachim Breitner wrote:
> Thomas, in your case, I guess the bug needs to be reassigned against
> gcc, as it might be an error in the profiling code created by gcc.

My only motivation was GHC, so I'm happy now, thanks. Should anyone else need
it fixed for gcc as well, feel free to reassign and contact me with questions
about the test case if needed.

(Is it intentional that the only e-mail I got about this bugreport is this one
where you explicitly Cc'd me? Do you guys get e-mail from Debian BTS? Shall I
report it to the bts clerks or is this a PEBKAC on my side?)

Regards,
-- 
Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/

Message #69 received at 575534@bugs.debian.org (full text, mbox, reply):

From: "GHC" <cvs-ghc@haskell.org>

Cc: glasgow-haskell-bugs@haskell.org

Subject: Re: [GHC] #4074: Forking not possible with large processes

Date: Thu, 27 May 2010 12:43:48 -0000

#4074: Forking not possible with large processes
--------------------------------------+-------------------------------------
  Reporter:  nomeata                  |          Owner:  simonmar        
      Type:  bug                      |         Status:  closed          
  Priority:  normal                   |      Milestone:  6.12.3          
 Component:  Runtime System           |        Version:  6.12.1          
Resolution:  fixed                    |       Keywords:                  
Difficulty:  Easy (less than 1 hour)  |             Os:  Linux           
  Testcase:                           |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown             |  
--------------------------------------+-------------------------------------
Changes (by marcotmarcot):

 * cc: marcot@… (added)


Comment:

 I could reproduce the bug with a GHC built just before the patch was
 applied, and I couldn't reproduce it with a GHC built just after the patch
 was applied, so I assume this patch fixes the bug.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4074#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

Message #80 received at 575534-done@bugs.debian.org (full text, mbox, reply):

From: Joachim Breitner <nomeata@debian.org>

To: 575534-done@bugs.debian.org

Subject: Fix included in new version

Date: Fri, 03 Jun 2011 00:05:47 +0200

[Message part 1 (text/plain, inline)]

Version: 7.0.3-1
-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.