Patch to process

Yusaku Hashimoto nonowarn at
Tue May 19 06:36:09 EDT 2009

I think I had not described context or purpose of my patch in last
mail. I'm going to explain the details about why the error occurs and
how the patch works. before and from I sent the patch, I have
inspected about them. So the detail was complicated but
interesting for me, I enjoyed it.

Well, this patch seems to be useful only on the old-fashiond Mac OS X
10.4.11, because no same error is not reported from anyone, and I'm an
only ghc user who uses Mac OS X 10.4.11. And ghc seemed to has quitted
to support the 10.4. This implies the patch should not be applied to
the repository. But if there are a few users like me, my patch and
report may be useful for (him|her).

In this report, we will make sure that what the error is, then trying
to write minimal reproducing code, in last, write appropriate patch.

First, What error has occured? It is occured when building
ghc-6.10.3. Main compilation successed such as compiler and library,
but building documents with haddock failed. From the error messages
below, when haddock runs gcc, the signal with SIGVTALRM is arrived to
gcc's child process (of cc1).

     if ifBuildable/ifBuildable /Users/mate/work/ghc-6.10.3/packages  
integer-gmp && [ -d integer-gmp/dist/doc/html/*/src/ ]; then cp  
hscolour.css integer-gmp/dist/doc/html/*/src/; fi
     if ifBuildable/ifBuildable /Users/mate/work/ghc-6.10.3/packages  
base; then \
               cd base && /Users/mate/work/ghc-6.10.3/libraries/cabal- 
bin /usr/local/ghc-6.10.1/bin/ghc /Users/mate/work/ghc-6.10.3/ 
libraries/bootstrapping.conf haddock --html-location='../$pkg' \
                                         --hyperlink-source --with- 
haddock; \
     Preprocessing library base-
     Running hscolour for base-
     Preprocessing library base-
     Running Haddock for base-
     Warning: The documentation for the following packages are not  
installed. No
     links will be generated to these packages: rts-1.0
     i686-apple-darwin8-gcc-4.0.1: Internal error: Virtual timer  
expired (program cc1)
     Please submit a full bug report.
     See <URL:> for instructions.
     make: *** [doc.library.base] Error 1

Of course, this can be seen only when haddock runs gcc. So, how does
haddock invoke gcc? It uses process library that fork() process and
exec() command in posix environment. And what is the SIGVTALRM?
SIGVTALRM is sended to a process of haskell program with certain
interval by the timer. It used for the scheduler in ghc's rts.

So, I could reproduce it with c (not haskell, unfortunately). Here is  
the code.

     #include <stdio.h>
     #include <stdlib.h>
     #include <unistd.h>
     #include <signal.h>
     #include <sys/types.h>
     #include <sys/wait.h>

     void ignore (int sig) {}

     void start_timer(void) {
         struct itimerval t;
         struct sigaction a;

         a.sa_handler = ignore;
         a.sa_flags = 0;
         sigaction(SIGVTALRM, &a, NULL);

         t.it_value.tv_sec = 0;
         t.it_value.tv_usec = 1000;
         t.it_interval = t.it_value;
         setitimer(ITIMER_VIRTUAL, &t, NULL);

     void loop (unsigned n) {
         while (--n)

     void exec_gcc(void) {
         char * args[] = {"gcc", "-xc", "-", NULL};
         execvp("gcc", args);

     int main(void) {
         pid_t p;
         int s;


         switch (p = fork()) {
         case 0:

             while (!waitpid(p, &s, WNOHANG)) loop(1000000);

         return s;

When this code execute, start the timer for make SIGVTALRM arrived
with certaion interval, and make the process own to ignore it. Then
fork and exec the gcc, so child process will try to read c code from
stdin and compile it, but it will be fail with signal is arrived to
child process. The below output assumes above code saved as

     $ gcc minimul_example.c -o minimul_example
     $ ./minimul_example
     # Control-D typed here
     i686-apple-darwin8-gcc-4.0.1: Internal error: Virtual timer  
expired (program cc1)
     Please submit a full bug report.
     See <URL:> for instructions.

So, error messages may be slightly different that depends what the
gcc's compile phase on signal arriving, but it is same that
compilation fails with the signal.

Now, We can see what to do. Stop the timer before fork. This is done
in the patch created with darcs attached to the mail last I sent, but
I will paste important part of this. Informations for darcs are

     hunk ./cbits/runProcess.c 66
          // shared between parent and child), and the parent behaves  
as if
          // the signal had been raised.
     +	stopTimer();

          switch(pid = fork())
     hunk ./cbits/runProcess.c 71
          case -1:
     +		startTimer();
              if (fdStdIn == -1) {
     hunk ./cbits/runProcess.c 189
     +	startTimer();

          return pid;

In the above, `.' is top directory of
[process]( And we must
remember start the timer after fork in parent process. After patch
applied, I tested the code with testsuite, It seemed to be fine.

That's all. I hope it can't be reproduced on 10.5.


On 2009/05/16, at 8:37, Yusaku Hashimoto wrote:

> Hi,
> I have a patch to process If this patch is considered to  
> be useful, Please apply.
> This patch solves strange haddock death, in Mac OS X 10.4.11 with  
> intel CPU. Details are described in 
> prerelease-td23346957.html
> Thanks,
> Hashimoto
> <1242387095.dpatch>

More information about the Libraries mailing list