<div dir="ltr"><div>Hi,</div><div><br></div><div>You're likely just hitting a memory leak, Haskell DLLs and the RTS aren't designed to be unload-able, which is why you can't call hs_init again after you stop.</div><div><br></div><div>The leak happens only when you do a foreign export because foreign exports create C wrappers to initializers for each function you export.</div><div><a href="https://github.com/ghc/ghc/blob/21f0f56164f50844c2150c62f950983b2376f8b6/compiler/deSugar/DsForeign.hs#L668">https://github.com/ghc/ghc/blob/21f0f56164f50844c2150c62f950983b2376f8b6/compiler/deSugar/DsForeign.hs#L668</a></div><div><br></div><div>These are marked as static initializers, and as such the CRT will initialize them on 
DLL_PROCESS_ATTACH

 time. At DLL_PROCESS_DETACH</div><div>time the destructors would be run, but we don't have destructors for these initializers, so whatever they did will always persist.</div><div><br></div><div>Your use case is fairly uncommon, but file a bug report against the leaks anyway. Why do you need to keep loading and unloading the dll?</div><div><br></div><div>Note that FreeLibrary like dlclose on unix does not guarantee that the library is freed, it just decrements the reference count. and when it</div><div>reaches 0 it will *eventually* unload it. Notice that if you use UnmapViewOfFile instead of FreeLibrary the leak doesn't happen as that</div><div>*actually* immediately unmaps the image.  But this will get you in all sorts of trouble later on when terminating (you'll likely segfault at that point).</div><div><br></div><div>Things will get worse when you actually do call hs_init, because hs_init will call initLinker which will load libraries of it's own. Unloading the top level</div><div>does not decrease the reference counts of the dependencies, and we do no extra work to ensure this.</div><div><br></div><div>If you really need to load/reload libraries, then I fear your only choice is some kind of process isolation and communicating back using share memory/pipes</div><div>or some sort of IPC.</div><div><br></div><div>Regards,</div><div>Tamar<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 27, 2018 at 4:33 PM Ольга Филиппская <<a href="mailto:olga.kenobi@gmail.com">olga.kenobi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif;font-size:large">It's true that one must initialize the runtime when calling Haskell from C/C++. We do this in the real project and just a pair of calls hs_init/hs_exit causes memory to be leaked even faster. But I tried to construct the minimal example to describe the bug, so I reduced all the extra-code.<br></div></div><br><div class="gmail_quote"><div dir="ltr">пн, 27 авг. 2018 г. в 18:00, Vanessa McHale <<a href="mailto:vanessa.mchale@iohk.io" target="_blank">vanessa.mchale@iohk.io</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p>I don't know about C++, but I do know that when calling Haskell
      from C code one must initialize the runtime and then exit it once
      finished. I also know that one must only initialize the runtime
      once over the course of the program's run. As far as I can tell,
      this does not occur in your example.<br>
    </p>
    <br>
    <div class="m_995815712482589492m_4013136087292307013moz-cite-prefix">On 08/27/2018 09:44 AM, Ольга
      Филиппская wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div class="gmail_default" style="font-family:georgia,serif;font-size:large">
          <div class="gmail_default">Hello.</div>
          <div class="gmail_default"><br>
          </div>
          <div class="gmail_default" style="font-family:Arial,Helvetica,sans-serif;font-size:small"><font face="georgia, serif" size="4"><i>Summary: </i>memory is
              consumed without releasing when a Haskell DLL (that uses
              FFI) is loaded and unloaded in an endless loop.</font><br>
          </div>
          <div class="gmail_default"><br>
          </div>
          <div class="gmail_default"><i>Details</i>: I'm working on a
            C++ project relying on a DLL that uses Haskell code. The DLL
            was built with GHC 8.0.1 x64, OS is Windows 7. (Newer
            versions of GHC - 8.2.1 and later - do not allow you to
            build such DLLs due to some bugs: <a href="https://ghc.haskell.org/trac/ghc/ticket/14472#no2" target="_blank">ticket #1</a>, <a href="https://ghc.haskell.org/trac/ghc/ticket/14784#no1" target="_blank">ticker #2</a>). The
            C++ project was built with MSVC compiler 2015.</div>
          <div class="gmail_default"><br>
          </div>
          <div class="gmail_default" style="font-family:Arial,Helvetica,sans-serif;font-size:small"><font face="georgia, serif" size="4">We noticed that memory is
              not released when the library is unloaded. I've
              constructed a baseline example to reproduce the bug. It
              has three files: the first one is <b>HaskellSources.hs</b>(see
              attachments). It contains one foreign export function foo.
              This foreign export function is necessary to reproduce the
              bug. The second file is <b>CWrapper.cpp</b>. I
              intentionally didn't include any Haskell function export
              because they make no difference for this example. The last
              file is the code of the main program (see <b>main.cpp</b>)
              that loads the library and unloads it at once in an
              endless loop.</font><br>
          </div>
          <div class="gmail_default"><br>
          </div>
          <div class="gmail_default" style="font-family:Arial,Helvetica,sans-serif;font-size:small">
            <div class="gmail_default"><font face="georgia, serif" size="4">There are two cases: whether HaskellExports.o
                is included into the library or not.</font></div>
            <div class="gmail_default"><font face="georgia, serif" size="4">1. HaskellExports.o is not included into the
                library (see attached build script<i> build_no_hs.sh</i>).
                Everything works just fine (i.e. amount of memory
                consumed by the app is the same before DLL loading and
                right after unloading.)</font></div>
            <div class="gmail_default"><font face="georgia, serif" size="4">2. HaskellExports.o is included into the
                library (see <i>build_w_hs.sh</i>). Memory is not
                released after unloading the DLL, after repeated
                load/unload cycles memory consumption keeps growing
                until finally the application crashes.</font></div>
            <div class="gmail_default"><font face="georgia, serif" size="4"><br>
              </font></div>
            <div class="gmail_default"><font face="georgia, serif" size="4">Is this a known problem? Is it tracked in your
                bugtracker? (Or maybe it is not a problem at all and I'm
                doing it wrong).</font></div>
            <div class="gmail_default"><font face="georgia, serif" size="4"><br>
              </font></div>
            <div class="gmail_default"><font face="georgia, serif" size="4">Thank you for your time.</font></div>
          </div>
        </div>
        <div><br>
        </div>
        -- <br>
        <div dir="ltr" class="m_995815712482589492m_4013136087292307013gmail_signature">
          <div dir="ltr"><i>
              <div class="gmail_default" style="font-family:georgia,serif;font-size:large;display:inline">Olga
                Philippskaya</div>
              .</i><br>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="m_995815712482589492m_4013136087292307013mimeAttachmentHeader"></fieldset>
      <br>
      <pre>_______________________________________________
ghc-devs mailing list
<a class="m_995815712482589492m_4013136087292307013moz-txt-link-abbreviated" href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>
<a class="m_995815712482589492m_4013136087292307013moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
    </blockquote>
  </div>

_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_995815712482589492gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><i>Филиппская Ольга.</i><br></div></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>