Profiling under 6.4.1 and Solaris segfaults

[Nils Anders Danielsson]

Running a simple Hello World program compiled with a GHC 6.4.1
snapshot (20050820) and profiling turned on (-prof -auto-all) under
Solaris results in a segfault. The core dump is similar to a core dump
posted earlier
(http://www.mail-archive.com/glasgow-haskell-bugs@haskell.org/msg04621.html):

(gdb) where
#0  0x0003df8c in EnterFunCCS ()
#1  0x0004a714 in stg_PAP_info ()
#2  0x00045538 in schedule ()
#3  0x00045ff8 in waitThread_ ()
#4  0x00045f48 in scheduleWaitThread ()
#5  0x0004258c in rts_evalLazyIO ()
#6  0x0003bea8 in main ()

The other core dump was due to not compiling the entire program with
profiling turned on. However, the profiling libraries are installed,
so I see no reason why that should be the case now. On the other hand,
when I compile with -fno-implicit-prelude (and main = main), I don't
get a core dump.

Have other Solaris users experienced something similar? I don't have
any problems with the Linux snapshot from the same day.

-- 
/NAD

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

Re: Automatically derived instances

[Marc A. Ziegert]

just try to compile it with

 ghc -fallow-overlapping-instances -Wall --make Main.hs

or inseart sth. like this at the first line:

 {-# OPTIONS -fglasgow-exts -fffi -fallow-undecidable-instances 
-fallow-overlapping-instances #-}

- marc



Am Montag, 29. August 2005 05:25 schrieb Juan Carlos Arevalo Baeza:
> David Menendez wrote:
> 
> >Juan Carlos Arevalo Baeza writes:
> >
> >  
> >
> >The way Haskell type classes
> >work, the overlap is determined without looking at the context, so "Show
> >a" will overlap with every possible instance for Show, including Show
> >Int, which is predefined.
> >  
> >
> 
>Ah. :-P Bummer.
> 
> >I'm not sure what the official justification for that is, but reason is
> >to avoid situations like this:
> >
> >class A t where a :: t
> >class B t where b :: t
> >class C t where c :: t
> >
> >instance A t => C t where c = a
> >instance B t => C t where c = b
> >
> >instance A Char where a = 'a'
> >instance B Char where b = 'b'
> >
> >What should c :: Char evaluate to?
> >  
> >
> 
>Right. Ambiguity. But as long as there's no ambiguity, there's no 
> reason to be this restrictive. Oh, well.
> 
> JCAB
> 
> ___
> Glasgow-haskell-users mailing list
> 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