runProcess+removeFile, Windows, possibly finaliser not running

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

runProcess+removeFile, Windows, possibly finaliser not running

Esa Ilari Vuokko
Hi!

I have been compiling GHC (from cvs head) in Windows :-)

Fine, I removed usage of sleep in some profiler thingy, so it compiled
and I could continue with build.

But when build get to the point compiling Network.Socket (I think),
hsc2hs barfed permission denied-error (even on repeated attempts) when
(apparently) removing temporary executable it had created.

Well, my fix was to use try $ removeFile foo, slightly unoptimal solution ;-)

Because error was permission problem, there isn't much choice why it
happens - running process in Windows locks executable while there is
an unclosed handle to it.  It is apparent that
libraries/base/System/Internals.hs, line 106 forward
mkProcessHandle :: PHANDLE -> IO ProcessHandle
mkProcessHandle h = do
   ioref <- newIORef h
   mkWeakIORef ioref (c_CloseHandle h)
   return (ProcessHandle ioref)

attaches some sort of finaliser to it (why it's done this way?).

The only sensible solution that springs to mind is to broaden handle
to contain space for exit code for process (or whatever information is
required) and on call to waitProcess/getProcessExitCode gather this
information, close the handle and change the handle to INVALID_HANDLE.
 Also, finaliser would need to ignore such handle, as closing handle
twice is error (possibly also dangerous if handles can rotate, but I
don't know if that is possible).

It'd be nice if this was fixed.  If noone more knowledgeable has time
to poke this, I might give it a go.

I suspect there are more such issues, based on errors I have sometimes
experienced with darcs, maybe it'd need to be tackled by having a
table of weak resources (possibly inside IO?)  that could be run
between actions or on request?

Best regards,
--Esa
_______________________________________________
Glasgow-haskell-bugs mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Reply | Threaded
Open this post in threaded view
|

RE: runProcess+removeFile, Windows, possibly finaliser not running

Simon Marlow
On 17 November 2005 04:06, Esa Ilari Vuokko wrote:

> Fine, I removed usage of sleep in some profiler thingy, so it compiled
> and I could continue with build.

where exactly?  I haven't seen this.

> But when build get to the point compiling Network.Socket (I think),
> hsc2hs barfed permission denied-error (even on repeated attempts) when
> (apparently) removing temporary executable it had created.
>
> Well, my fix was to use try $ removeFile foo, slightly unoptimal
> solution ;-)
>
> Because error was permission problem, there isn't much choice why it
> happens - running process in Windows locks executable while there is
> an unclosed handle to it.  It is apparent that
> libraries/base/System/Internals.hs, line 106 forward
> mkProcessHandle :: PHANDLE -> IO ProcessHandle
> mkProcessHandle h = do
>    ioref <- newIORef h
>    mkWeakIORef ioref (c_CloseHandle h)
>    return (ProcessHandle ioref)
>
> attaches some sort of finaliser to it (why it's done this way?).

I made this change recently so that repeated calls to waitForProcess or
terminateProcess would be possible without getting an error about closed
handles.

I've just improved it so that the handle is now closed eagerly, but
still finalized if it isn't referenced.  This should fix the hsc2hs
problem (which incedentally I couldn't reproduce for some reason).

> The only sensible solution that springs to mind is to broaden handle
> to contain space for exit code for process (or whatever information is
> required) and on call to waitProcess/getProcessExitCode gather this
> information, close the handle and change the handle to INVALID_HANDLE.
>  Also, finaliser would need to ignore such handle, as closing handle
> twice is error (possibly also dangerous if handles can rotate, but I
> don't know if that is possible).

yes, this is pretty much what I did.
 
Cheers,
        Simon
_______________________________________________
Glasgow-haskell-bugs mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Reply | Threaded
Open this post in threaded view
|

Re: runProcess+removeFile, Windows, possibly finaliser not running

Esa Ilari Vuokko
On 11/17/05, Simon Marlow <[hidden email]> wrote:
> On 17 November 2005 04:06, Esa Ilari Vuokko wrote:
>
> > Fine, I removed usage of sleep in some profiler thingy, so it compiled
> > and I could continue with build.
>
> where exactly?  I haven't seen this.

Wierd.

Index: ghc/utils/prof/cgprof/main.c
===================================================================
RCS file: /cvs/fptools/ghc/utils/prof/cgprof/main.c,v
retrieving revision 1.3
diff -u -r1.3 main.c
--- ghc/utils/prof/cgprof/main.c 13 Aug 2004 13:11:23 -0000 1.3
+++ ghc/utils/prof/cgprof/main.c 17 Nov 2005 05:23:08 -0000
@@ -115,7 +115,7 @@

   /* printf("Initialisation done\n"); */

-  if (Verbose) sleep(10);
+  /*if (Verbose) sleep(10);  */
   if (!(fptr=fopen(ProfileData,"r"))) {
     fprintf(stderr,"%s: unable to open profile data in \"%s\".\n%s\n",
             Pgm,ProfileData,usage);


> > attaches some sort of finaliser to it (why it's done this way?).
>
> I made this change recently so that repeated calls to waitForProcess or
> terminateProcess would be possible without getting an error about closed
> handles.

Ah.

> I've just improved it so that the handle is now closed eagerly, but
> still finalized if it isn't referenced.  This should fix the hsc2hs
> problem (which incedentally I couldn't reproduce for some reason).

Worst kind of bugs :-(

> > The only sensible solution that springs to mind is to broaden handle
> > to contain space for exit code for process (or whatever information is
> > required) and on call to waitProcess/getProcessExitCode gather this
> > information, close the handle and change the handle to INVALID_HANDLE.
> >  Also, finaliser would need to ignore such handle, as closing handle
> > twice is error (possibly also dangerous if handles can rotate, but I
> > don't know if that is possible).
>
> yes, this is pretty much what I did.

Thanks!
--Esa
_______________________________________________
Glasgow-haskell-bugs mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs