http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241

--- Comment #5 from Kai Tietz <ktietz at gcc dot gnu.org> 2011-02-09 09:40:28 
UTC ---
So it seems to be an issue of lto and file-caching. There is a dangling
file-handle, which can cause this issue.

Could you please test the following patch, if it solves the unlink issue?
Please make sure that lto-plugin is unmodified version.

Thanks in advance,
Kai

Index: lto.c
===================================================================
--- lto.c    (revision 169962)
+++ lto.c    (working copy)
@@ -593,7 +593,11 @@
       fd_name = xstrdup (file_data->file_name);
       fd = open (file_data->file_name, O_RDONLY|O_BINARY);
       if (fd == -1)
-    return NULL;
+        {
+          free (fd_name);
+          fd_name = NULL;
+      return NULL;
+    }
     }

 #if LTO_MMAP_IO
@@ -619,9 +623,17 @@
       || read (fd, result, len) != (ssize_t) len)
     {
       free (result);
-      return NULL;
+      result = NULL;
     }
-
+#ifdef __MINGW32__
+  /* Native windows doesn't supports delayed unlink on opened file. So
+     We close file here again. This produces higher I/O load, but at least
+     it prevents to have dangling file handles preventing unlink.  */
+  free (fd_name);
+  fd_name = NULL;
+  close (fd);
+  fd = -1;
+#endif
   return result;
 #endif
 }

Reply via email to