If you aren't using anything unsafe, then it is a bug. Even if you are using something unsafe, it might still be a bug; either way if you can narrow down to the smallest program (+data) that crashes that would be immensely helpful. Does the result change if you use different GC settings? I like to use +RTS -A8k to force GC to happen as often as possible, it helps to flush out GC problems earlier. Cheers, Simon On 05/04/2010 20:05, Philip Weaver wrote:

Yes, I can do that. However, I'm hoping to narrow it down a lot more so that I can file a more useful bug report.

Since sending my last email, I have learned a bit more:

I was using 'fail' (the Monad being ReaderT . StateT . ST) to report errors. If I replace 'fail msg' with 'error msg' or 'return (error msg)', then the aforementioned internal error does not occur.

In some cases, the program dies with the aforementioned error. In other cases, it segfaults.

- Philip

On Mon, Apr 5, 2010 at 11:59 AM, Don Stewart mailto:dons@galois.com> wrote:

Any 'internal error' is almost certainly an RTS or compiler bug. Can you make a bug report?

philip.weaver: > Hi all, > > A program that I built with GHC is crashing at runtime with the following > error: > > internal error: eval_thunk_selector: strange selectee 12 > > I have not found much via Google, just an old post regarding ghc 6.0 that > recommends cleaning and rebuilding. I have cleaned the build directory and > re-built the executable, and I still get the error. > > The program is a compiler, and this error began showing up after I added > support for memoization of results using the ST Monad and STRefs. For example, > the following function creates a reference to a thunk: > > newMutableRef m > = do ref <- newSTRef $ error "access ref too soon!" > let m' = do r <- m > writeSTRef ref (return r) > return r > writeSTRef ref m' > return $ ref > > Here's some information about my system: > > • GHC 6.12.1 > • Mac OS X 10.6.3 (Snow Leopard) > > So, what could cause this error? Any suggestions that can help me narrow down > the problem would be greatly appreciated. If this is in fact a GHC bug, I'd > like to find a workaround for now and also reproduce it in a small example so I > can file a bug report. > > - Philip >

> _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org mailto:Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users