Mark Tehver | 1 Aug 09:55 2003
Picon

DLL problem with GHC 6.0.1

Hi,

I have run into something in GHC that looks
like a bug (GHC 6.0.1 under Win2k). A DLL with several exported
FFI functions reports (and then terminates):

ghcDll: internal error: schedule: invalid what_next field
    Please report this as a bug to glasgow-haskell-bugs <at> haskell.org,
    or http://www.sourceforge.net/projects/ghc/

What is really strange: I get this error ONLY when I run my
application (C++ code which loads the DLL dynamically) under MS
Visual Studio 6 in Debug Mode. When I run the same executable
from shell/command prompt, then everything works. Also, when I
compile the DLL with GHC version 5.x, I can run the application
from Visual Studio 6 without problems. So this seems to be GHC 6.x specific.

Not 100% sure, but looks like I get this error on a first call to
any FFI function. Unfortunately the application is rather large but
I could try to simplify it. I had this problem also with GHC 6.0.0.
Any ideas?

Regards,
Mark Tehver
SourceForge.net | 4 Aug 13:32 2003
Picon
Picon

[ ghc-Bugs-782761 ] Wrong line count in parsec under linux on dos-style files

Bugs item #782761, was opened at 2003-08-04 04:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=782761&group_id=8032

Category: hslibs/text
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong line count in parsec under linux on dos-style files

Initial Comment:
Parsec doubles the line count (reported e.g. in a parse error) when run (at least on a linux box) on DOS-style
files (with DOS-style newlines)

I have GHC 6.0

My e-mail address is nick.name <at> inwind.it

Bye

Vincenzo Ciancia

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=782761&group_id=8032
(Continue reading)

Simon Marlow | 4 Aug 15:09 2003
Picon

RE: DLL problem with GHC 6.0.1


> I have run into something in GHC that looks
> like a bug (GHC 6.0.1 under Win2k). A DLL with several exported
> FFI functions reports (and then terminates):
> 
> ghcDll: internal error: schedule: invalid what_next field
>     Please report this as a bug to glasgow-haskell-bugs <at> haskell.org,
>     or http://www.sourceforge.net/projects/ghc/
> 
> What is really strange: I get this error ONLY when I run my
> application (C++ code which loads the DLL dynamically) under MS
> Visual Studio 6 in Debug Mode. When I run the same executable
> from shell/command prompt, then everything works. Also, when I
> compile the DLL with GHC version 5.x, I can run the application
> from Visual Studio 6 without problems. So this seems to be 
> GHC 6.x specific.
> 
> Not 100% sure, but looks like I get this error on a first call to
> any FFI function. Unfortunately the application is rather large but
> I could try to simplify it. I had this problem also with GHC 6.0.0.
> Any ideas?

Just wondering: are you using the DLL wrapper code that comes with
H/Direct?  (it looks like it from the error message - ghcDll is what
that wrapper uses as the dummy binary name).

If you're using H/Direct, then there are one or two bugs in the DLL
support that I believe have been fixed recently.  In particular,
DllCanUnloadNow() was bogusly returning S_OK all the time, which could
lead to the crash you mention above.  Change DllCanUnloadNow to
(Continue reading)

SourceForge.net | 4 Aug 20:16 2003
Picon
Picon

[ ghc-Bugs-782761 ] Wrong line count in parsec under linux on dos-style files

Bugs item #782761, was opened at 2003-08-04 04:32
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=782761&group_id=8032

Category: hslibs/text
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong line count in parsec under linux on dos-style files

Initial Comment:
Parsec doubles the line count (reported e.g. in a parse error) when run (at least on a linux box) on DOS-style
files (with DOS-style newlines)

I have GHC 6.0

My e-mail address is nick.name <at> inwind.it

Bye

Vincenzo Ciancia

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2003-08-04 11:16
(Continue reading)

Iavor Diatchki | 6 Aug 01:42 2003
Picon

compiler (simplifier) loops

hello,

the following program makes the compiler (version 6.0.1) loop.
the same seems to happen on 5.04.2.
when i run it with -v, it seems that it gets stuck in the simplifier.

 > newtype T a = Close { open :: T a -> a }
 >
 > fix :: (a -> a) -> a
 > fix f = s (Close s)
 >  where s x = f (open x x)

also the flag:
-fmax-simplifier-iterations
is not recognized on 6.0.1

bye
iavor

--

-- 
==================================================
| Iavor S. Diatchki, Ph.D. student               |
| Department of Computer Science and Engineering |
| School of OGI at OHSU                          |
| http://www.cse.ogi.edu/~diatchki               |
==================================================
Simon Peyton-Jones | 6 Aug 13:36 2003
Picon

RE: compiler (simplifier) loops

A known infelicity; see the bottom of
	
http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html

My hypothesis is that this only happens if you try to make it happen.
I've never found it happen in a real program.  Let me know if that's not
the case.

Simon

| -----Original Message-----
| From: glasgow-haskell-bugs-admin <at> haskell.org
[mailto:glasgow-haskell-bugs-admin <at> haskell.org] On
| Behalf Of Iavor Diatchki
| Sent: 06 August 2003 00:42
| To: glasgow-haskell-bugs <at> haskell.org
| Subject: compiler (simplifier) loops
| 
| hello,
| 
| the following program makes the compiler (version 6.0.1) loop.
| the same seems to happen on 5.04.2.
| when i run it with -v, it seems that it gets stuck in the simplifier.
| 
|  > newtype T a = Close { open :: T a -> a }
|  >
|  > fix :: (a -> a) -> a
|  > fix f = s (Close s)
|  >  where s x = f (open x x)
| 
(Continue reading)

Gregory Wright | 7 Aug 04:53 2003
Picon
Picon

ghc 6.0.1 and Mac OS X 10.2.6 build


Hi,

I've built ghc 6.0.1 under OS X 10.2.6 and have a curious problem with 
ghci.
ghc seems to work fine, but ghci give me an error. I should note that 
I've done
the build without Wolfgang's HaskellSupportFramework, by setting the 
include
and library paths in build.mk. This is more compatible with the 
automated packing
scheme of DarwinPorts.

This is what I see:

bash-2.05a$ ghci
    ___         ___ _
   / _ \ /\  /\/ __(_)
  / /_\// /_/ / /  | |      GHC Interactive, version 6.0.1, for Haskell 
98.
/ /_\\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.

Loading package base ... linking ...
/usr/local/lib/ghc-6.0.1/HSbase_cbits.o: unknown symbol `_free'
ghc-6.0.1: panic! (the `impossible' happened, GHC version 6.0.1):
         can't load package `base'

Please report it as a compiler bug to glasgow-haskell-bugs <at> haskell.org,
or http://sourceforge.net/projects/ghc/.
(Continue reading)

Donald Bruce Stewart | 7 Aug 04:58 2003
Picon
Picon

Re: ghc 6.0.1 and Mac OS X 10.2.6 build

gwright:
> 
> Hi,
> 
> I've built ghc 6.0.1 under OS X 10.2.6 and have a curious
> problem with ghci.  ghc seems to work fine, but ghci give me an
> error. I should note that I've done the build without
> Wolfgang's HaskellSupportFramework, by setting the include and
> library paths in build.mk. This is more compatible with the
> automated packing scheme of DarwinPorts.
> 
> This is what I see:
> 
> bash-2.05a$ ghci
>    ___         ___ _
>   / _ \ /\  /\/ __(_)
>  / /_\// /_/ / /  | |      GHC Interactive, version 6.0.1, for Haskell 
> 98.
> / /_\\/ __  / /___| |      http://www.haskell.org/ghc/
> \____/\/ /_/\____/|_|      Type :? for help.
> 
> Loading package base ... linking ...
> /usr/local/lib/ghc-6.0.1/HSbase_cbits.o: unknown symbol `_free'
> ghc-6.0.1: panic! (the `impossible' happened, GHC version 6.0.1):
>         can't load package `base'
> 
> Please report it as a compiler bug to glasgow-haskell-bugs <at> haskell.org,
> or http://sourceforge.net/projects/ghc/.
> 
> 
(Continue reading)

Gregory Wright | 7 Aug 05:17 2003
Picon
Picon

Re: ghc 6.0.1 and Mac OS X 10.2.6 build


On Wednesday, August 6, 2003, at 10:58 PM, Donald Bruce Stewart wrote:

> gwright:
>>
>> Hi,
>>
>> I've built ghc 6.0.1 under OS X 10.2.6 and have a curious
>> problem with ghci.  ghc seems to work fine, but ghci give me an
>> error. I should note that I've done the build without
>> Wolfgang's HaskellSupportFramework, by setting the include and
>> library paths in build.mk. This is more compatible with the
>> automated packing scheme of DarwinPorts.
>>
>> This is what I see:
>>
>> bash-2.05a$ ghci
>>    ___         ___ _
>>   / _ \ /\  /\/ __(_)
>>  / /_\// /_/ / /  | |      GHC Interactive, version 6.0.1, for Haskell
>> 98.
>> / /_\\/ __  / /___| |      http://www.haskell.org/ghc/
>> \____/\/ /_/\____/|_|      Type :? for help.
>>
>> Loading package base ... linking ...
>> /usr/local/lib/ghc-6.0.1/HSbase_cbits.o: unknown symbol `_free'
>> ghc-6.0.1: panic! (the `impossible' happened, GHC version 6.0.1):
>>         can't load package `base'
>>
>> Please report it as a compiler bug to 
(Continue reading)

Wolfgang Thaller | 7 Aug 09:46 2003
Picon
Picon

Re: ghc 6.0.1 and Mac OS X 10.2.6 build

> I should note that I've done
> the build without Wolfgang's HaskellSupportFramework, by setting the 
> include
> and library paths in build.mk. This is more compatible with the 
> automated packing
> scheme of DarwinPorts.

Of course. The HaskellSupport.framework isn't necessary when the user 
already has DarwinPorts installed; be sure to note somewhere that 
GHC-compiled programs will require gmp and dlcompat.

> by setting the include
> and library paths in build.mk.

The "official" way to disable the HaskellSupport.framework is to modify 
configure.in (yes, I should really add a --configure option for that):

Lines 978 to 991 read:
dnl ** (Mac OS X only: check for HaskellSupport.framework)
HaveFrameworkHaskellSupport=NO
if test $HostPlatform = "powerpc-apple-darwin"; then
  AC_MSG_CHECKING([for HaskellSupport.framework])
  save_libs="$LIBS"
  LIBS="-framework HaskellSupport"
  AC_TRY_LINK_FUNC(__gmpz_fdiv_qr, HaveFrameworkHaskellSupport=YES,)
  if test $HaveFrameworkHaskellSupport = YES; then
   AC_DEFINE(HAVE_FRAMEWORK_HASKELLSUPPORT)
  fi;
  LIBS="$save_libs"
  AC_MSG_RESULT([$HaveFrameworkHaskellSupport])
(Continue reading)


Gmane