Patch to process 1.0.1.1
Hi, I have a patch to process 1.0.1.1. 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 http://www.nabble.com/6.10.3- prerelease-td23346957.html Thanks, Hashimoto
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 1.6.0.3 haddock --html-location='../$pkg' \
--hyperlink-source --with-
haddock=/Users/mate/work/ghc-6.10.3/utils/haddock/install-inplace/bin/
haddock; \
fi
Preprocessing library base-4.1.0.0...
Running hscolour for base-4.1.0.0...
Preprocessing library base-4.1.0.0...
Running Haddock for base-4.1.0.0...
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:http://developer.apple.com/bugreporter 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
Hi,
I have a patch to process 1.0.1.1. 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 http://www.nabble.com/6.10.3- prerelease-td23346957.html
Thanks, Hashimoto
<1242387095.dpatch>
Hi Yusaku,
So your patch doesn't get lost, can I suggest you file a GHC bug
report and attach your patch to that?
http://hackage.haskell.org/trac/ghc/wiki/ReportABug
Thanks for the work in putting together a patch,
Neil
On Tue, May 19, 2009 at 11:36 AM, Yusaku Hashimoto
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 1.6.0.3 haddock --html-location='../$pkg' \ --hyperlink-source --with-haddock=/Users/mate/work/ghc-6.10.3/utils/haddock/install-inplace/bin/haddock; \ fi Preprocessing library base-4.1.0.0... Running hscolour for base-4.1.0.0... Preprocessing library base-4.1.0.0... Running Haddock for base-4.1.0.0... 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:http://developer.apple.com/bugreporter 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
#include #include #include #include #include void ignore (int sig) {}
void start_timer(void) { struct itimerval t; struct sigaction a;
a.sa_handler = ignore; a.sa_flags = 0; sigemptyset(&a.sa_mask); 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;
start_timer();
switch (p = fork()) { case 0: exec_gcc();
default: 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 minimul_example.c.
$ gcc minimul_example.c -o minimul_example $ ./minimul_example main(){puts("foo");} # 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:http://developer.apple.com/bugreporter 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 ignored.
hunk ./cbits/runProcess.c 66 // shared between parent and child), and the parent behaves as if // the signal had been raised. blockUserSignals(); + stopTimer();
switch(pid = fork()) { hunk ./cbits/runProcess.c 71 case -1: + startTimer(); unblockUserSignals(); if (fdStdIn == -1) { close(fdStdInput[0]); hunk ./cbits/runProcess.c 189 } break; } + startTimer(); unblockUserSignals();
return pid;
In the above, `.' is top directory of [process](http://darcs.haskell.org/packages/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.
Thanks, Hashimoto
On 2009/05/16, at 8:37, Yusaku Hashimoto wrote:
Hi,
I have a patch to process 1.0.1.1. 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 http://www.nabble.com/6.10.3-prerelease-td23346957.html
Thanks, Hashimoto
<1242387095.dpatch>
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Thank you for suggestion, Neil. I have created a ticket on trac. http://hackage.haskell.org/trac/ghc/ticket/3243 Thanks, Hashimoto On 2009/05/19, at 19:49, Neil Mitchell wrote:
Hi Yusaku,
So your patch doesn't get lost, can I suggest you file a GHC bug report and attach your patch to that? http://hackage.haskell.org/trac/ghc/wiki/ReportABug
Thanks for the work in putting together a patch,
Neil
On Tue, May 19, 2009 at 11:36 AM, Yusaku Hashimoto
wrote: 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 1.6.0.3 haddock --html-location='../$pkg' \ --hyperlink-source --with-haddock=/Users/mate/work/ghc-6.10.3/utils/haddock/install- inplace/bin/haddock; \ fi Preprocessing library base-4.1.0.0... Running hscolour for base-4.1.0.0... Preprocessing library base-4.1.0.0... Running Haddock for base-4.1.0.0... 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:http://developer.apple.com/bugreporter 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
#include #include #include #include #include void ignore (int sig) {}
void start_timer(void) { struct itimerval t; struct sigaction a;
a.sa_handler = ignore; a.sa_flags = 0; sigemptyset(&a.sa_mask); 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;
start_timer();
switch (p = fork()) { case 0: exec_gcc();
default: 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 minimul_example.c.
$ gcc minimul_example.c -o minimul_example $ ./minimul_example main(){puts("foo");} # 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:http://developer.apple.com/bugreporter 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 ignored.
hunk ./cbits/runProcess.c 66 // shared between parent and child), and the parent behaves as if // the signal had been raised. blockUserSignals(); + stopTimer();
switch(pid = fork()) { hunk ./cbits/runProcess.c 71 case -1: + startTimer(); unblockUserSignals(); if (fdStdIn == -1) { close(fdStdInput[0]); hunk ./cbits/runProcess.c 189 } break; } + startTimer(); unblockUserSignals();
return pid;
In the above, `.' is top directory of [process](http://darcs.haskell.org/packages/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.
Thanks, Hashimoto
On 2009/05/16, at 8:37, Yusaku Hashimoto wrote:
Hi,
I have a patch to process 1.0.1.1. 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 http://www.nabble.com/6.10.3-prerelease-td23346957.html
Thanks, Hashimoto
<1242387095.dpatch>
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Yusaku Hashimoto wrote:
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).
You're not the only one on OSX 10.4. I'm rather saddened by the lack of GHC support for 10.4 recently (it's like not supporting XP now that Vista is out). Alas. -- Live well, ~wren
On 19/05/2009 21:40, wren ng thornton wrote:
Yusaku Hashimoto wrote:
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).
You're not the only one on OSX 10.4. I'm rather saddened by the lack of GHC support for 10.4 recently (it's like not supporting XP now that Vista is out). Alas.
Now fixed, it looks like this was an accidental regression in 6.10.2. Sorry about that. 6.10.4 will have the fix. Cheers, Simon
On 2009/05/21, at 0:06, Simon Marlow wrote:
Now fixed, it looks like this was an accidental regression in 6.10.2. Sorry about that. 6.10.4 will have the fix.
Great!
Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Yusaku Hashimoto wrote:
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.
No, there are many GHC users on Tiger. This bug was being tracked on MacPorts, because everyone thought it was a problem with Xcode 2.5. Simon Marlow wrote:
Now fixed, it looks like this was an accidental regression in 6.10.2. Sorry about that. 6.10.4 will have the fix.
Yusaku, thanks for your great work in tracking down this bug and getting it fixed! -Yitz
participants (5)
-
Neil Mitchell -
Simon Marlow -
wren ng thornton -
Yitzchak Gale -
Yusaku Hashimoto