Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Debugging on Mac OS X
Luke Worth [EMAIL PROTECTED] wrote: I just installed GHC 6.6 using the PPC binary installer on Mac OS X. I'm having some trouble getting debuggers to work; I have tried both plargleflarp (buddha) and Hat. Neither of them will compile on GHC 6.6 on Mac yet. As an interim measure, I have just made available a 'snapshot' release of Hat-2.05, specifically to ensure that it compiles with ghc-6.6. This is very much a stop-gap. There have been huge changes in the standard base library package since the last full release of Hat, which are not reflected in 2.05. (For example, Parsec and Data.FiniteMap are no longer in base, whilst Data.Map, Data.Set and so on have been added. Hat still has the older API.) The Hat team is planning to rectify these problems shortly, but we are unlikely to be able to make a full release before the end of the year. I hope the 2.05 release is sufficient to meet at least some people's needs in the meantime. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Heap representation evil
Brandon Moore wrote:
Thinking to take advantage of fortuitous heap layout of some Haskell
values for interfacing with C, I've written the following function:
addressOf :: a - Ptr ()
addressOf x = x `seq` unsafeCoerce# (Box x)
data Box x = Box x
For example,
data A = A {-# UNPACK #-} !(Ptr Word8) {-# UNPACK #-} !CInt
main = let a = A nullPtr 12
p = addressOf a `plusPtr` 4
in do x - peek p :: IO Int
y - peek p :: IO Int
print (x, y)
prints
(0, 12)
One thing I don't understand is that this fails if I use Just
rather than inventing my box type. I suppose the info table for
Just is set up to support a vectored return for pattern matching
on Maybe?
Yes, exactly right.
(the commentary isn't very clear here. The section
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution#ReturnConvention
says, in full:
Return Convention
Direct Returns
Vectored Returns
)
Sorry, I haven't got around to writing that section yet!
The reason I'm messing about with this stuff is that I'm pretty sure
passing p to C code would give a usable pointer to
struct a {char *; int;};
Obviously my plot will be spoiled if the GC comes along and relocates
the value while C code is trying to use it.
Yes.
Are there any other pitfalls with this approach?
The GC pitfall not enough for you? :) Well, future GHC versions might change
the representation under your feet, since we don't consider the heap object
representation to be stable, user-visible stuff.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Debugging on Mac OS X
For general info on debugging, make sure to check the wiki page: http://www.haskell.org/haskellwiki/Debugging And while you are there maybe you can add some notes on your experience. In case you want to play with the GHCi debugger, I've been updating the repository with the latest ghc 6.6 patches these days, so it is still alive and working. Unfortunately, you still will need to compile it yourself (just to make it clear, this means compiling a custom version of GHC). Cheers pepe On 23/10/2006, at 14:42, Luke Worth wrote: Hi all, I just installed GHC 6.6 using the PPC binary installer on Mac OS X. I'm having some trouble getting debuggers to work; I have tried both plargleflarp (buddha) and Hat. Neither of them will compile on GHC 6.6 on Mac yet. For anyone in the same situation, how do you survive? I know of no other method of debugging Haskell programs, aside from manually running chunks of the code from within GHCi - but that makes it very difficult to debug nested 'where' functions. Thanks in advance Luke Worth ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
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 windows.h
#include Rts.h
extern void __stginit_ExternLib(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_ExternLib);
return TRUE;
}
return TRUE;
}
ExternLib.hs is the external Haskell program that I link to but I don't
actually call. I could probably generate a simple example of the problem,
which perhaps I shall do and post shortly.
--
View this message in context:
http://www.nabble.com/GHC-6.4.1-and-Win32-DLLs%3A-Bug-in-shutdownHaskell--tf1206938.html#a6978317
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
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 windows.h
#include Rts.h
extern void __stginit_ExternLib(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_ExternLib);
return TRUE;
}
return TRUE;
}
ExternLib.hs -
module ExternLib where
foreign export stdcall hinc :: Double - Double
hinc :: Double - Double
hinc dval = dval + 1.0
- matlabinterf.c -
#include stdlib.h
#include string.h
#include assert.h
#include stdio.h
#include mex.h
#ifndef FFI_H
#define FFI_H
typedef unsigned int HsChar; // on 32 bit machine
typedef int HsInt;
typedef unsigned int HsWord;
typedef void *HsPtr;
typedef void (*HsFunPtr)(void);
typedef void *HsForeignPtr;
typedef void *HsStablePtr;
typedef double HsDouble ;
#define HS_BOOL_FALSE 0
#define HS_BOOL_TRUE 1
#endif // FFI_H
__declspec(dllimport) HsDouble __stdcall hinc(HsDouble ival) ;
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
HsDouble *ival, *oval ;
mxArray *mret ;
/* We check the number of input and output arguments*/
if (nrhs != 1)
mexErrMsgTxt(Error: this needs 1 input argument) ;
ival = mxGetPr(prhs[0]) ;
/* create a 1 x 1 real matrix for the output */
mret = mxCreateDoubleMatrix(1,1, mxREAL) ;
plhs[0] = mret ;
oval = mxGetPr(plhs[0]) ;
*oval = hinc(*ival) ;
}
Here is the batch file I use to create the Haskell DLL. It assumes MS VC
tools are in the
search path.
--- ghcdll.bat --
ghc -O2 -c ExternLib.hs -fglasgow-exts
ghc -c dllNet.c
ghc --mk-dll -fglasgow-exts -o interf.dll ExternLib.o ExternLib_stub.o
dllNet.o -L. -optdll--def -optdllinterf.def
lib /def:interf.def /MACHINE:X86
-- interf.def
LIBRARYinterf.dll
EXPORTS
[EMAIL PROTECTED]
hinc = [EMAIL PROTECTED]
Run the following commands in Matlab to load and unload the Haskell DLL
mex matlabinterf.c interf.lib
y = matlabinterf(0)
clear matlabinterf
Matlab will crash with an unhandled exception after calling a floating point
division operation. It is possible to actually make it so that the haskell
code is not called at all but merely linked and thus loaded when the dll is
loaded. The crash still occurs. I suspect Matlab must be accessing some
kind of resource used by the DLL that is not shut down properly when the DLL
is unloaded. However in more complicated examples Matlab will eventually
crash after multiple calls to perfectly good Haskell code, whether or not
the DLL is unloaded. Next I will try to see if I can duplicate this outside
of a Matlab environment.
--
View this message in context:
http://www.nabble.com/GHC-6.4.1-and-Win32-DLLs%3A-Bug-in-shutdownHaskell--tf1206938.html#a6980729
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
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). ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
