Hi Folks, As you may know, support on MacOS X/PowerPC hardware has been lacking a bit recently: there are outstanding showstoppers with 6.4.2. Our Mac hero Wolfgang Thaller has been busy, and hasn't had time to look into the problems or package 6.4.2 for MacOS X (at least I assume he's busy, that's the last I heard, but he didn't respond to my latest ping). So the mantle of powerpc-apple-darwin maintainer is probably up for grabs. 6.4.3 is held up because of this (but not just because of this). Can anyone help out? Relevant bugs: http://hackage.haskell.org/trac/ghc/ticket/751 http://hackage.haskell.org/trac/ghc/ticket/766 and Wolfgang, if you're listening, we miss you :-) Cheers, Simon
X (at least I assume he's busy, that's the last I heard, but he didn't respond to my latest ping).
Oops, sorry about that. Yes, I'm quite busy, trying to get a degree here. Proper Mac OS X support will resume on September 1st :-).
So the mantle of powerpc-apple-darwin maintainer is probably up for grabs. 6.4.3 is held up because of this (but not just because of this). Can anyone help out?
GHC/Mac OS X users, I know you are out there, and I know that many of you are capable of building GHC and running gdb on it! Please step forward now! Similar things to be said for the Mac OS X/Intel port, which is "basically there", but which I will not finish before I both a) finish my degree and b) get an actual Intel based Mac of my own. So another job opening there. Cheers, Wolfgang
Simon, I submitted a patch for ticket #766 this afternoon. I've banged my head on ticket #751, building with debugging symbols and running under gdb, but have yet to get any useful information that would pin down the bug. Best, Greg On Jul 5, 2006, at 10:47 AM, Simon Marlow wrote:
Hi Folks,
As you may know, support on MacOS X/PowerPC hardware has been lacking a bit recently: there are outstanding showstoppers with 6.4.2. Our Mac hero Wolfgang Thaller has been busy, and hasn't had time to look into the problems or package 6.4.2 for MacOS X (at least I assume he's busy, that's the last I heard, but he didn't respond to my latest ping).
So the mantle of powerpc-apple-darwin maintainer is probably up for grabs. 6.4.3 is held up because of this (but not just because of this). Can anyone help out?
Relevant bugs:
http://hackage.haskell.org/trac/ghc/ticket/751 http://hackage.haskell.org/trac/ghc/ticket/766
and Wolfgang, if you're listening, we miss you :-)
Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Gregory Wright wrote:
I submitted a patch for ticket #766 this afternoon.
Thanks, now comitted and merged.
I've banged my head on ticket #751, building with debugging symbols and running under gdb, but have yet to get any useful information that would pin down the bug.
Does http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes help at all? Cheers, Simon
Hi Simon, I followed the instruction in DebuggingGhcCrashes, and the instructions in the ghc commentary for building an rts with debugging and symbols. (Please let me know if there are any mistakes in these instructions that you know of!) The crash seems to always happen eventually, but I do not have a simple case that reproduces it quickly. Gdb's traceback doesn't give anything immediately useful, so I assume that the crash is in haskell code, not in C. The not-always-reproducible nature of the bug suggests deferencing a pointer into uninitialized memory. Both 6.4.2 and HEAD show the problem on OS X. It can be avoided by disabling the threaded rts, but that is not acceptable solution. If I am to take a few deep breaths and dive back into the problem, which branch should I use, 6.4.x or HEAD? Best Wishes, Greg On Jul 6, 2006, at 8:13 AM, Simon Marlow wrote:
Gregory Wright wrote:
I submitted a patch for ticket #766 this afternoon.
Thanks, now comitted and merged.
I've banged my head on ticket #751, building with debugging symbols and running under gdb, but have yet to get any useful information that would pin down the bug.
Does http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes help at all?
Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Gregory Wright wrote:
I followed the instruction in DebuggingGhcCrashes, and the instructions in the ghc commentary for building an rts with debugging and symbols. (Please let me know if there are any mistakes in these instructions that you know of!)
The crash seems to always happen eventually, but I do not have a simple case that reproduces it quickly. Gdb's traceback doesn't give anything immediately useful, so I assume that the crash is in haskell code, not in C. The not-always-reproducible nature of the bug suggests deferencing a pointer into uninitialized memory.
Both 6.4.2 and HEAD show the problem on OS X. It can be avoided by disabling the threaded rts, but that is not acceptable solution.
This is a good datapoint, because it probably rules out much of the threaded RTS code in the RTS itself, which has changed significantly between 6.4.x and HEAD.
If I am to take a few deep breaths and dive back into the problem, which branch should I use, 6.4.x or HEAD?
No preference, since it's probably the same bug in both. Use whatever's easiest for you. Cheers, Simon
Hi Simon, On Jul 7, 2006, at 4:26 AM, Simon Marlow wrote:
Gregory Wright wrote:
I followed the instruction in DebuggingGhcCrashes, and the instructions in the ghc commentary for building an rts with debugging and symbols. (Please let me know if there are any mistakes in these instructions that you know of!) The crash seems to always happen eventually, but I do not have a simple case that reproduces it quickly. Gdb's traceback doesn't give anything immediately useful, so I assume that the crash is in haskell code, not in C. The not-always-reproducible nature of the bug suggests deferencing a pointer into uninitialized memory. Both 6.4.2 and HEAD show the problem on OS X. It can be avoided by disabling the threaded rts, but that is not acceptable solution.
This is a good datapoint, because it probably rules out much of the threaded RTS code in the RTS itself, which has changed significantly between 6.4.x and HEAD.
A quick question: does the darcs repository have go back to 6.4.1? (The place to start looking a diff of the RTS from 6.4.1, which worked, and 6.4.2 or HEAD, which doesn't).
If I am to take a few deep breaths and dive back into the problem, which branch should I use, 6.4.x or HEAD?
No preference, since it's probably the same bug in both. Use whatever's easiest for you.
I'll work with HEAD. Best Wishes, Greg
Cheers, Simon
Simon Marlow schrieb:
Gregory Wright wrote:
Both 6.4.2 and HEAD show the problem on OS X. It can be avoided by disabling the threaded rts, but that is not acceptable solution.
This is a good datapoint, because it probably rules out much of the threaded RTS code in the RTS itself, which has changed significantly between 6.4.x and HEAD.
Could you summarize the advantages (or need) of the threaded RTS? It doesn't work under solaris and under linux [1] my nightly compilation jobs are "killed" every tuesday morning (!) for some reason that i cannot reproduce. I suspect the threaded RTS and heavy load. I had no such problems with ghc-6.4.1 before. As a friend of pure functions I hate such a non-deterministic behaviour of a (mere) compiler. Cheers Christian [1] http://www.haskell.org/ghc/dist/6.4.2/ghc-6.4.2-i386-unknown-linux.tar.bz2
Christian Maeder schrieb:
Could you summarize the advantages (or need) of the threaded RTS?
It doesn't work under solaris
I'm quite content with my non-threaded 6.4.2-cvs version under solaris (and I was already looking for a switch -non-threaded under linux). C.
Christian Maeder
It doesn't work under solaris and under linux [1] my nightly compilation jobs are "killed" every tuesday morning (!) for some reason that i cannot reproduce. I suspect the threaded RTS and heavy load. I had no such problems with ghc-6.4.1 before.
A process can be "Killed" by the operating system if the machine runs out of virtual memory. I suspect someone else is running a cron job on Tuesdays that fills memory. It is unlikely to be (only) ghc's fault. Regards, Malcolm
Malcolm Wallace schrieb:
A process can be "Killed" by the operating system if the machine runs out of virtual memory. I suspect someone else is running a cron job on Tuesdays that fills memory.
Yes, I also run other jobs and the load is high. In fact the OOM-killer kills ghc-6.4.2 several times as is shown in the log messages. Probably ghc is requesting memory then. Other jobs are not killed, though. Cheers Christian OOM = out-of-memory
Christian Maeder wrote:
Simon Marlow schrieb:
Gregory Wright wrote:
Both 6.4.2 and HEAD show the problem on OS X. It can be avoided by disabling the threaded rts, but that is not acceptable solution.
This is a good datapoint, because it probably rules out much of the threaded RTS code in the RTS itself, which has changed significantly between 6.4.x and HEAD.
Could you summarize the advantages (or need) of the threaded RTS?
The reason we added it to the compiler was so that you could use programs that require -threaded under GHCi. Without it, these programs cannot be used with GHCi. In general, -threaded is the way forward, and at some point I hope we can make it the default (I was considering this for 6.6, actually). Without -threaded, all FFI calls block the other threads in the program, and this makes it impossible to do lots of things.
It doesn't work under solaris and under linux [1] my nightly compilation jobs are "killed" every tuesday morning (!) for some reason that i cannot reproduce. I suspect the threaded RTS and heavy load. I had no such problems with ghc-6.4.1 before.
What version of glibc are you using on Linux? There were bugs in glibc that could cause deadlocks occasionally, I remember having to upgrade glibc on our RedHat 9 box a while back. We know about the threaded RTS bugs on Sparc, and 6.4.3 won't be released without a fix for this. I'm actually quite glad that we've forced this into the open with 6.4.2, otherwise the bug would probably have remained dormant, affecting only those who used -threaded on Sparc. Cheers, Simon
Simon Marlow schrieb:
The reason we added it to the compiler was so that you could use programs that require -threaded under GHCi. Without it, these programs cannot be used with GHCi.
Surely, running user programs is different from just compiling.
Without -threaded, all FFI calls block the other threads in the program, and this makes it impossible to do lots of things.
Obviously, I only want that (my old) sequentiell things are done as reliable (one at a time) as before.
What version of glibc are you using on Linux?
glibc-devel-2.3.4-23.4 glibc-locale-2.3.4-23.4 glibc-info-2.3.4-23.4 glibc-html-2.3.4-23 glibc-2.3.4-23.4 glibc-i18ndata-2.3.4-23.4 C.
On 07 July 2006 11:46, Christian Maeder wrote:
Simon Marlow schrieb:
The reason we added it to the compiler was so that you could use programs that require -threaded under GHCi. Without it, these programs cannot be used with GHCi.
Surely, running user programs is different from just compiling.
GHC and GHCi are the same binary.
Without -threaded, all FFI calls block the other threads in the program, and this makes it impossible to do lots of things.
Obviously, I only want that (my old) sequentiell things are done as reliable (one at a time) as before.
And they will be - the threaded RTS only affects FFI calls on multithreaded programs.
What version of glibc are you using on Linux?
glibc-devel-2.3.4-23.4 glibc-locale-2.3.4-23.4 glibc-info-2.3.4-23.4 glibc-html-2.3.4-23 glibc-2.3.4-23.4 glibc-i18ndata-2.3.4-23.4
I guess that isn't it, I have 2.3.2 here. Cheers, Simon
On Fri, 2006-07-07 at 11:28 +0100, Simon Marlow wrote:
We know about the threaded RTS bugs on Sparc, and 6.4.3 won't be released without a fix for this. I'm actually quite glad that we've forced this into the open with 6.4.2, otherwise the bug would probably have remained dormant, affecting only those who used -threaded on Sparc.
As far as I know this does not affect Sparc Linux, only Sparc Solaris. Duncan
On Fri, Jul 07, 2006 at 11:28:44AM +0100, Simon Marlow wrote: Hi,
We know about the threaded RTS bugs on Sparc, and 6.4.3 won't be released without a fix for this. I'm actually quite glad that we've forced this into the open with 6.4.2, otherwise the bug would probably have remained dormant, affecting only those who used -threaded on Sparc.
Solaris x86 has similar bugs with the RTS (like mentioned in previous posts). A summary: 6.4 branch from cvs changed the occurrence a bit - it is harder to reproduce it - but possible - and now it segfaults (before - 6.4.2 - it hanged). To try a debug enabled -threaded version of ghc and follow http://hackage.haskell.org/trac/ghc/wiki/DebuggingGhcCrashes is on my TODO list. Regards Georg Sauthoff
Christian Maeder schrieb:
It doesn't work under solaris and under linux [1] my nightly compilation jobs are "killed" every tuesday morning (!) for some reason that i cannot reproduce. I suspect the threaded RTS and heavy load. I had no such problems with ghc-6.4.1 before.
I withdraw my suspicion against the threaded RTS under linux. I was able to provoke also ghc-6.4.1 being killed by the OOM-Killer (when no swap space was left). The process state of ghc-6.4.1 seems to be more often "uninterruptible sleep", though. Cheers Christian
participants (8)
-
Christian Maeder -
Duncan Coutts -
Georg Sauthoff -
Gregory Wright -
Malcolm Wallace -
Simon Marlow -
Simon Marlow -
Wolfgang Thaller