
On 27 July 2004 11:17, David Roundy wrote:
I've been trying to track down a "Bus error" that one of my users is getting on the macintosh, and am at the point of having just one idea as to what might be causing it.
The error happens during garbage collection, as far as I can tell. He compiled darcs using ghc 6.2.1.
My only theory is that perhaps hGetBuf (or maybe hPutBuf) isn't actually synchronous on some platforms? If this were the case, of course, using h{Get,Put}Buf on a pointer within withForeignPtr might be dangerous, since the ForeignPtr could be GCed before the hGetBuf actually takes place. It's hard to imagine that this actually is the case, but I'm really running out of ideas as to what could cause this bus error he's seeing. It's not 100% reproducible, but goes away if he makes the GC triggered less often (in darcs I trigger GCs manually before doing a large mallocForeignPtr to keep memory usage down), and when we added a debug message finalizer, he sees it considerably less often. Alas, I've been unable to reproduce it myself, and his repository that displays this behavior contains private data.
Any suggestions and/or insight would be welcome.
hGetBuf is synchronous; the system will not write to the buffer after hGetBuf returns. hPutBuf is also synchronous, in the sense that the data to be written is copied out of the buffer passed in, and either written right away or placed in the Handle's buffer ready to be written at a later time. So I don't think your hypothetical scenario is happening, sounds like it must be something else. There has been one GC bug found since 6.2.1, which could perhaps be the cause. Try getting your user to compile up an RTS from the latest CVS sources of the 6.2 branch and see if that helps. Cheers, Simon

On Tue, Jul 27, 2004 at 02:36:39PM +0100, Simon Marlow wrote:
hGetBuf is synchronous; the system will not write to the buffer after hGetBuf returns. hPutBuf is also synchronous, in the sense that the data to be written is copied out of the buffer passed in, and either written right away or placed in the Handle's buffer ready to be written at a later time.
So I don't think your hypothetical scenario is happening, sounds like it must be something else.
There has been one GC bug found since 6.2.1, which could perhaps be the cause. Try getting your user to compile up an RTS from the latest CVS sources of the 6.2 branch and see if that helps.
I just got a report that the CVS version of 6.2.1 doesn't show the error! :) -- David Roundy http://www.abridgegame.org
participants (2)
-
David Roundy
-
Simon Marlow