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 <windows.h>
#include <Rts.h>

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 <[EMAIL PROTECTED]>
Subject: Re: Missing Folder in ghc?
To: glasgow-haskell-users@haskell.org
Message-ID: <[EMAIL PROTECTED]>
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.



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

Reply via email to