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