
When the intermediate files are removed, GHC still hangs. In fact, the
intermediate files do not seem to be corrupt in any way, as the only way to
get a working executable is to run GHC more than once. First to produce the
intermediate files, then to link them into an executable.
On 5/7/07, Cale Gibbard
On 07/05/07, Josiah Manson
wrote: There is still a problem when I use the version you linked to. At first I was hopeful, because the first time I tried compiling bisect.hs it worked. All subsequent attempts, however, have failed.
Maybe try getting rid of all the intermediate (*.hi *.o) files created when compiling it? Not that this is necessarily a permanent solution...
- Cale

On 5/7/07, Josiah Manson
When the intermediate files are removed, GHC still hangs. In fact, the intermediate files do not seem to be corrupt in any way, as the only way to get a working executable is to run GHC more than once. First to produce the intermediate files, then to link them into an executable.
At this point I'd probably do something like running FileMon (http://www.microsoft.com/technet/sysinternals/FileAndDisk/Filemon.mspx) and its allied tools to see if I could determine what is touching what files when. Maybe that's overkill but it has occasionally helped me. -- Dan

I have generated log files with both filemon and procmon. The procmon output
may be useful. ghc.exe launches gcc.exe which launches as.exe which does
various things, but the last thing as.exe does before all goes silent is
this line:
16555 10:24:30.0592945 PM as.exe 4364 RegOpenKey
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics NAME NOT
FOUND Desired Access: Read
The very last thing as.exe does is fail to open a registry key. Is this the
problem? Maybe, but I still think the behavior feels like deadlock, because
sometimes compilation hangs while sometimes it does not, and when it hangs
there is no CPU usage.
On 5/7/07, Dan Piponi
On 5/7/07, Josiah Manson
wrote: When the intermediate files are removed, GHC still hangs. In fact, the intermediate files do not seem to be corrupt in any way, as the only way to get a working executable is to run GHC more than once. First to produce the intermediate files, then to link them into an executable.
At this point I'd probably do something like running FileMon (http://www.microsoft.com/technet/sysinternals/FileAndDisk/Filemon.mspx) and its allied tools to see if I could determine what is touching what files when. Maybe that's overkill but it has occasionally helped me. -- Dan

On Mon, May 07, 2007 at 10:43:04PM -0500, Josiah Manson wrote:
problem? Maybe, but I still think the behavior feels like deadlock, because sometimes compilation hangs while sometimes it does not, and when it hangs there is no CPU usage.
Can you get ghc -v output of (a) it hanging and (b) it not hanging? Does it hang with both -fvia-C and -fasm? Thanks Ian
participants (3)
-
Dan Piponi
-
Ian Lynagh
-
Josiah Manson