Getting StackOverflowException on windows.

[Cynede]

In Samples.

they are compiling but only HelloWorld.exe works w/o StackOverflowException

minimal code for Exception:

main = withCLR $ do
    hSetBuffering stdout NoBuffering

    -- Make an MVar to hold the result of the download when it has completed
    done <- newEmptyMVar 


    -- Create a delegate that accepts a single argument and puts it into the
    -- MVar when called
    finished <- delegate _ParameterizedThreadStart (putMVar done)
    return ()

in bindings:

--
-- Delegate: ParameterizedThreadStart
--

type Type_wrap_stub_53 = ObjectId -> IO ()
foreign import ccall "wrapper" wrap_stub_53 :: Type_wrap_stub_53 -> (IO (FunPtr Type_wrap_stub_53))

{-# NOINLINE stub_53 #-}
stub_53 :: Type_wrap_stub_53 -> IO ObjectId
stub_53 = unsafePerformIO $ getDelegateConstructorStub
    "System.Threading.ParameterizedThreadStart, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
    wrap_stub_53

instance Delegate ParameterizedThreadStart_ where
    type DelegateT ParameterizedThreadStart_ = (Obj Object_) -> IO ()
    delegate _ handler = stub_53 (marshalFn1 handler) >>= unmarshal

[tim-m89]

Hi Heather. I some how haven't been getting the notifications so only just noticed this issue had been raised yesterday. I've managed to reproduce the issue and I'll update you on my investigation. Cheers

[Cynede]

@tim-m89 hello, I'm really glad to see your answer!

Also I'm trying to run on .NET 4 Framework, review it please: #6

However good that you already can reproduce it.

[tim-m89]

I haven't had as much time as I'd like to devote to projects lately as you can probably see by now.

From the little investigation I have done, it doesn't appear to be unbound recursion. I found that various things in the C# driver dll would cause the exception, though with a slight re-write would be ok. Some experimentation for example, found that the 1st place was this line in 'CreateDelegateWrapperType':

ilg.Emit(OpCodes.Call, MemberInfos.Object_ctor);

And rewriting the member infos from:

    internal static class MemberInfos
    {
        public static readonly MethodInfo Type_GetTypeFromHandle =
            typeof(Type).GetMethod("GetTypeFromHandle");

        public static readonly ConstructorInfo Object_ctor =
            typeof(object).GetConstructor(Type.EmptyTypes);

        public static readonly MethodInfo Marshal_GetDelegateForFunctionPointer =
            typeof(Marshal).GetMethod("GetDelegateForFunctionPointer");

        public static readonly MethodInfo Marshal_GetFunctionPointerForDelegate =
            typeof(Marshal).GetMethod("GetFunctionPointerForDelegate");

        public static readonly MethodInfo Marshal_StringToHGlobalUni =
            typeof(Marshal).GetMethod("StringToHGlobalUni");

        public static readonly MethodInfo Marshal_StringToHGlobalAnsi =
            typeof(Marshal).GetMethod("StringToHGlobalAnsi");

        public static readonly FieldInfo Driver_FreeHaskellFunPtr =
            typeof(Driver).GetField("FreeHaskellFunPtr", BindingFlags.Static | BindingFlags.Public);

        public static readonly MethodInfo Driver_RegisterObject =
            typeof(Driver).GetMethod("RegisterObject", BindingFlags.Static | BindingFlags.Public);

        public static readonly MethodInfo Driver_GetObject =
            typeof(Driver).GetMethod("GetObject", BindingFlags.Static | BindingFlags.Public);

        public static readonly MethodInfo FreeHaskellFunPtrDelegate_Invoke =
            typeof(FreeHaskellFunPtrDelegate).GetMethod("Invoke");
    }

So that each is instead a normal method with a return statement and the exceptions were no longer thrown from these areas. The stack overflow exceptions were also getting thrown at other points. I found that 'Type.GetMethod' would throw but writing another implementation to to do the same utilizing 'GetMethods' with own filtering logic would be fine.

It seems unlikely that the runtime would have unbound recursion bugs, so perhaps the stack is simply insufficiently sized. GHC has various options affecting stack size in Running a compiled program but I had no luck in getting a response from these options.

Some .Net or C# settings may work, but we've also the unusual scenario of hosting the runtime, and calling into it from a Haskell foreign function interface so it might not be so straight forward.

[tim-m89]

The .Net hosting API here is using the old deprecated interfaces. Testing out with the newer API (ICLRRuntimeHost instead of ICorRunTimeHost) and I found issues were present in starting the runtime (ICLRRuntimeHost Start will fail with 0x80004005). I created a test library in C that would start the runtime host and a simple executable in both C and Haskell that simply call into it. Only the C executable would work. It looks like the ghc runtime is interfering in ways described here: https://mail.haskell.org/pipermail/ffi/2012-April/001865.html & https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals#RTSAlarmSignalsandForeignLibraries