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 <[email protected]
<mailto:[email protected]>> 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
> [email protected]
<mailto:[email protected]>
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
