GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
Hello *,
before filing a bug report, I want others to comment on my problem.
Maybe it's my fault, not ghc's.
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
The memory allocated by the runtime system is never freed. I've submitted a fix fir this. -- Lennart Michael Marte wrote:
Hello *,
before filing a bug report, I want others to comment on my problem. Maybe it's my fault, not ghc's.
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
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Lennart, do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed? I played around a little bit more and found two configurations that do not crash, at least not when freeing the DLL in the course of quitting the application: - compilation with -O, execution with standard heap size - compilation with -O, execution with -M128m. With 64m initial heap space, the problems described earlier occur again :-( Michael Lennart Augustsson wrote:
The memory allocated by the runtime system is never freed. I've submitted a fix fir this.
-- Lennart
I'm not implying anything, except that I've plugged the space leak of 256M every time a DLL is loaded&unloaded. -- Lennart Michael Marte wrote:
Lennart,
do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed?
I played around a little bit more and found two configurations that do not crash, at least not when freeing the DLL in the course of quitting the application: - compilation with -O, execution with standard heap size - compilation with -O, execution with -M128m. With 64m initial heap space, the problems described earlier occur again :-(
Michael
Lennart Augustsson wrote:
The memory allocated by the runtime system is never freed. I've submitted a fix fir this.
-- Lennart
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Lennart Augustsson wrote:
I'm not implying anything, except that I've plugged the space leak of 256M every time a DLL is loaded&unloaded.
-- Lennart
Michael Marte wrote:
Lennart,
do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed?
I wanted to test the fix for ticket #711 but I am stuck because there is no current snapshot of ghc 6.5 for mingw. (The last one is dated end of February, the patch was commited on March, 2nd.) I saw that the patch is scheduled for milestone 6.4.2 but has been commited only for 6.5. When will it be available for 6.4.2? I started learning to compile ghc and I have succeeded with the current head of the 6.4 branch on Debian Linux/testing. Next step is to compile the head on this system. My current problem is a missing symbol when linking stage1/ghc-6.5, namely u_gencat referenced by stage1/parser/Lexer.o. Am I missing some library? (I think my sources are up to date, I pulled only half an hour ago.) Michael
[I am resending this message with a new subject because nobody seems to be reading the old thread.] I wanted to test the fix for ticket #711 but I am stuck because there is no current snapshot of ghc 6.5 for mingw. (The last one is dated end of February, the patch was commited on March, 2nd.) I saw that the patch is scheduled for milestone 6.4.2 but has been commited only for 6.5. When will it be available for 6.4.2? I started learning to compile ghc and I have succeeded with the current head of the 6.4 branch on Debian Linux/testing. Next step is to compile the head on this system. My current problem is a missing symbol when linking stage1/ghc-6.5, namely u_gencat referenced by stage1/parser/Lexer.o. Am I missing some library? (I think my sources are up to date, I pulled only half an hour ago.) Michael
Michael Marte wrote:
Lennart Augustsson wrote:
I'm not implying anything, except that I've plugged the space leak of 256M every time a DLL is loaded&unloaded.
-- Lennart
Michael Marte wrote:
Lennart,
do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed?
I wanted to test the fix for ticket #711 but I am stuck because there is no current snapshot of ghc 6.5 for mingw. (The last one is dated end of February, the patch was commited on March, 2nd.)
The patch hasn't been committed at all, AFAIK.
I saw that the patch is scheduled for milestone 6.4.2 but has been commited only for 6.5. When will it be available for 6.4.2?
I started learning to compile ghc and I have succeeded with the current head of the 6.4 branch on Debian Linux/testing. Next step is to compile the head on this system. My current problem is a missing symbol when linking stage1/ghc-6.5, namely u_gencat referenced by stage1/parser/Lexer.o. Am I missing some library? (I think my sources are up to date, I pulled only half an hour ago.)
When compiling with 6.4.1 or later, u_gencat should come from libHSbase_cbits.a in your 6.4.1 installation. Is it there? Cheers, Simon
Simon Marlow wrote:
Michael Marte wrote:
Lennart Augustsson wrote:
I'm not implying anything, except that I've plugged the space leak of 256M every time a DLL is loaded&unloaded.
-- Lennart
Michael Marte wrote:
Lennart,
do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed?
I wanted to test the fix for ticket #711 but I am stuck because there is no current snapshot of ghc 6.5 for mingw. (The last one is dated end of February, the patch was commited on March, 2nd.)
The patch hasn't been committed at all, AFAIK.
Ok, it am new to Darcs, so this patch is only a proposal contained in the ticket?
I saw that the patch is scheduled for milestone 6.4.2 but has been commited only for 6.5. When will it be available for 6.4.2?
I started learning to compile ghc and I have succeeded with the current head of the 6.4 branch on Debian Linux/testing. Next step is to compile the head on this system. My current problem is a missing symbol when linking stage1/ghc-6.5, namely u_gencat referenced by stage1/parser/Lexer.o. Am I missing some library? (I think my sources are up to date, I pulled only half an hour ago.)
When compiling with 6.4.1 or later, u_gencat should come from libHSbase_cbits.a in your 6.4.1 installation. Is it there?
No, I am compiling with plain 6.4 (a newer Debain package is not available) and it does not have u_gencat in this library. However I can compile the head of the 6.4 branch which in turn should be able to compile the head, shouldn't it? Michael
Michael, I've found more bugs. There are several race conditions when a DLL is unloaded. The extra threads that the GHC runtime system starts (at least one is always started to generate timer ticks) are not shut down in a synchronized way. This means that they might be scheduled to run after the DLL has been unloaded. Which gives you an access violation. I don't have a proper fix for this yet. -- Lennart Michael Marte wrote:
Lennart,
do you imply that you have fixed the problem causing the crashes? May I safely assume that DLLs produced by ghc 6.4.2 will not crash upon being freed?
I played around a little bit more and found two configurations that do not crash, at least not when freeing the DLL in the course of quitting the application: - compilation with -O, execution with standard heap size - compilation with -O, execution with -M128m. With 64m initial heap space, the problems described earlier occur again :-(
Michael
Lennart Augustsson wrote:
The memory allocated by the runtime system is never freed. I've submitted a fix fir this.
-- Lennart
Lennart Augustsson wrote:
I've found more bugs. There are several race conditions when a DLL is unloaded. The extra threads that the GHC runtime system starts (at least one is always started to generate timer ticks) are not shut down in a synchronized way. This means that they might be scheduled to run after the DLL has been unloaded. Which gives you an access violation. I don't have a proper fix for this yet.
Is this with -threaded? Simon
No, the timer thread starts even without -threaded.
If you use -threaded it gets worse because then you have
a bunch of other threads that don't exit properly.
-- Lennart
Quoting Simon Marlow
Lennart Augustsson wrote:
I've found more bugs. There are several race conditions when a DLL is unloaded. The extra threads that the GHC runtime system starts (at least one is always started to generate timer ticks) are not shut down in a synchronized way. This means that they might be scheduled to run after the DLL has been unloaded. Which gives you an access violation. I don't have a proper fix for this yet.
Is this with -threaded?
Simon
Michael Marte wrote:
Hello *,
before filing a bug report, I want others to comment on my problem. Maybe it's my fault, not ghc's.
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.
I was wondering if there has been any recent progress on this issue. I have a binary windows distribution of GHC 6.5. from May 02 2006. I created a Haskell DLL that is called from a C stub, which ultimately gets called from Matlab. I'm not sure if Matlab loads and unloads the DLL everytime it's called, but it definately crashes Matlab if one tries to unload the DLL from inside Matlab (using Matlab's clear command). The crash occurs even if no Haskell code is actually called from Matlab. It suffices to simply load the Haskell DLL and then unload it. If you do call the DLL it will work for the first few times and then eventually crash. Presumably there is some kind of memory leak as alluded to elsewhere in this thread. I'm looking for usable workarounds here. -- View this message in context: http://www.nabble.com/GHC-6.4.1-and-Win32-DLLs%3A-Bug-in-shutdownHaskell--tf... Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
I am still using ghc 6.4.2 for creating my DLL and, as long as the DLL does not open a file, releasing the DLL works fine. I have not yet tried ghc 6.5. Michael SevenThunders wrote:
Michael Marte wrote:
Hello *,
before filing a bug report, I want others to comment on my problem. Maybe it's my fault, not ghc's.
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.
I was wondering if there has been any recent progress on this issue. I have a binary windows distribution of GHC 6.5. from May 02 2006.
I created a Haskell DLL that is called from a C stub, which ultimately gets called from Matlab. I'm not sure if Matlab loads and unloads the DLL everytime it's called, but it definately crashes Matlab if one tries to unload the DLL from inside Matlab (using Matlab's clear command). The crash occurs even if no Haskell code is actually called from Matlab. It suffices to simply load the Haskell DLL and then unload it.
If you do call the DLL it will work for the first few times and then eventually crash. Presumably there is some kind of memory leak as alluded to elsewhere in this thread. I'm looking for usable workarounds here.
Michael Marte wrote:
I am still using ghc 6.4.2 for creating my DLL and, as long as the DLL does not open a file, releasing the DLL works fine. I have not yet tried ghc 6.5.
Michael
I just tried it under GHC 6.6 with the same results. If the DLL is loaded it
crashes when it's unloaded even if no Haskell code is actually executed.
Again I am calling this from Matlab 6.5 so I have no idea how Matlab is
handling the loading and unloading of the DLL or what it is doing to the
environment. All that is clear is that if the code needs to be linked to
the Haskell DLL, the phenomenon occurs.
My DLL main program was lifted from the documentation and looks like this.
#include
SevenThunders wrote:
I just tried it under GHC 6.6 with the same results. If the DLL is loaded it crashes when it's unloaded even if no Haskell code is actually executed.
Here is the promised simple example. This example will cause an exception
when the DLL is unloaded, but it doesn't seem to cause the run time
exception that a more complicated example might cause. This could be
because of the very small amount of memory it actually uses.
-------- dllNet.c -----------------------------
#include
On Tue, 2006-10-24 at 13:16 -0700, SevenThunders wrote:
Here is the promised simple example. This example will cause an exception when the DLL is unloaded, but it doesn't seem to cause the run time exception that a more complicated example might cause. This could be because of the very small amount of memory it actually uses.
I know nothing of Matlab or Haskell linkage .. so do you know which C library they're linked against? It has to be the same one, and it must be dynamic linkage. (Felix build was inconsistent and we got similar random behaviour). -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
I'm not sure exactly how to determine which runtime libraries Matlab 6.5 uses. However since I am compiling the mex code via Microsoft VC++ 6.0, I suspect that the Haskell DLL s are loaded using the MS VC 6.0 runtime libraries. The DLL that contains the interface code however is probably loaded using whatever libraries Matlab links to. Ultimately they both should just be calling the operating system load and unload routines. How did you resolve your problems? skaller wrote:
On Tue, 2006-10-24 at 13:16 -0700, SevenThunders wrote:
Here is the promised simple example. This example will cause an exception when the DLL is unloaded, but it doesn't seem to cause the run time exception that a more complicated example might cause. This could be because of the very small amount of memory it actually uses.
I know nothing of Matlab or Haskell linkage .. so do you know which C library they're linked against? It has to be the same one, and it must be dynamic linkage. (Felix build was inconsistent and we got similar random behaviour).
participants (7)
-
Lennart Augustsson -
lennart＠augustsson.net
-
Matthew Bromberg -
Michael Marte -
SevenThunders
-
Simon Marlow -
skaller