Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?

Did you try to link the DLL statically (i.e. via import library) and remove the call to shutdownHaskell() ? It worked for me (I am using Visual Studio 7, though). Cheers, Cyril ___

I wrapped up some Haskell modules in a Win32 DLL. Loading the DLL dynamically (with LoadLibrary) works fine. However, whether I actually use the library or not, the program (an application with MFC GUI) crashes upon termination. To find the reason for the crash, I added a new function for unloading the DLL using FreeLibrary. FreeLibrary works fine, however the program crashes when it returns to the main event loop. Interestingly, when I reload the library (FreeLibrary followed by LoadLibrary) the program continues working. However, every reload cycle causes the virtual size of the process to increase by about 300K and the fourth reload fails with the error message "getMBlock: VirtualAlloc failed with: 8" (appears in a message window) accompanied by many repetitions of the message "Timer proc: wait failed -- error code: 6" (appears on stderr) and followed by the message "getMBlocks: misaligned block returned" (again in a message window). Then the programm crashes.

Development takes place on Windows XP Professional using MS Visual Studio 6.0 SP 5 and ghc 6.4.1. There are no references from the C++ side to the Haskell heap. I build the DLL using the command

ghc --mk-dll -optdll--def -optdllFoo.def -o Foo.dll Foo.o Foo_stub.o dllMain.c

dllMain.c looks as follows:

#include #include

extern void __stginit_EUzu3820zu85(void);

static char* args[] = { "ghcDll", NULL }; /* N.B. argv arrays must end with NULL */ BOOL STDCALL DllMain(HANDLE hModule, DWORD reason, void* reserved) { if (reason == DLL_PROCESS_ATTACH) { /* By now, the RTS DLL should have been hoisted in, but we need to start it up. */ startupHaskell(1, args, __stginit_Foo); return TRUE; } else if (reason == DLL_PROCESS_DETACH) { shutdownHaskell(); } return TRUE; }

I played around with hs_exit instead of shutdownHaskell, I moved initialization and clean-up from DllMain to my library loader, nothing helps. Even doing no clean-up whatsoever does not change the behaviour.

Any ideas? Michael

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

Message: 2 Date: Wed, 01 Mar 2006 12:06:27 -0800 From: Ashley Yakeley Subject: Re: Missing Folder in ghc? To: glasgow-haskell-users@haskell.org Message-ID: Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Simon Marlow wrote:

...

The configure script has mis-detected your GHC version somehow. Could you look through the output of configure, and see what it says about GHC?

Nothing special:

checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu Canonicalised to: i386-unknown-linux checking for path to top of build tree... /home/ashley/Projects/Collected/Haskell/ghc checking for ghc... /usr/bin/ghc checking version of ghc... 6.4 checking for nhc... no checking for nhc98... no checking for hbc... no

...

Also look in mk/config.mk, at the value of GhcCanonVersion.

GHC = /usr/bin/ghc GhcDir = $(dir $(GHC)) GhcVersion = 6.4 GhcMajVersion = 6 GhcMinVersion = 4 GhcPatchLevel = 0

# Canonicalised ghc version number, used for easy (integer) version # comparisons. We must expand $(GhcMinVersion) to two digits by # adding a leading zero if necessary: ifneq "$(findstring $(GhcMinVersion), 0 1 2 3 4 5 6 7 8 9)" "" GhcCanonVersion = $(GhcMajVersion)0$(GhcMinVersion) else GhcCanonVersion = $(GhcMajVersion)$(GhcMinVersion) endif

...

Maybe you switched GHC versions but didn't reconfigure?

I think the problem is that I called autoconf etc. before I called darcs-all get, but not after. Calling autoreconf fixed the problem.