Has anyone else seen this problem on XP Pro?
My Visual Studio 2008 IDE freezes during mid-build for a multi-project solution. The freeze occurs sometime after processing a project that was missing a file needed to satisfy a "USE" statement. When the missing file is added to the project/source list, the restarted build completes successfully. I first observed this behavior in 046, and went to 051 to see if this corrected the problem, which it did not.
I don't believe I've seen this behavior in earlier versions (9.x - 11.0) where the build actually terminated with errors, rather than forcing me to do Build/Cancel. During the freeze, Task Manager shows fortcom is using 50% of the CPU (on a dual core).
I tried to search for this problem, but I didn't see if this was mentioned already ... the search terms would be pretty generic. The build log (after the cancel) does show a problem with the missing module file, but otherwise is lacking any reason for freezing, such as internal compiler error messages.
My Visual Studio 2008 IDE freezes during mid-build for a multi-project solution. The freeze occurs sometime after processing a project that was missing a file needed to satisfy a "USE" statement. When the missing file is added to the project/source list, the restarted build completes successfully. I first observed this behavior in 046, and went to 051 to see if this corrected the problem, which it did not.
I don't believe I've seen this behavior in earlier versions (9.x - 11.0) where the build actually terminated with errors, rather than forcing me to do Build/Cancel. During the freeze, Task Manager shows fortcom is using 50% of the CPU (on a dual core).
I tried to search for this problem, but I didn't see if this was mentioned already ... the search terms would be pretty generic. The build log (after the cancel) does show a problem with the missing module file, but otherwise is lacking any reason for freezing, such as internal compiler error messages.
链接已复制
16 回复数
As an update to this problem description, I found that once the build process freezes, I can see the fortcom process in Task Manager using CPU cycles. Now if I end the fortcom process from Task Manager, then the build process in the IDE continues to completion.
The final build log then shows the compilation for the offending project was aborted (the result of my Task Manager action) and the rest of the log is usual and unremarkable.
A co-worker, also on IVF 11.1 reported the same lock-up behavior when a project build thread compiled with major syntax errors resulting in a (562) catastrophic error in the log and the subsequent freezing of the build process, requiring a Build/Cancel in the IDE.
This seems to imply that selected major compilation errors that occur in a thread are somehow leaving the thread in some kind of loop state (ie, using CPU) and never gets to report back to the monitoring process.
The final build log then shows the compilation for the offending project was aborted (the result of my Task Manager action) and the rest of the log is usual and unremarkable.
A co-worker, also on IVF 11.1 reported the same lock-up behavior when a project build thread compiled with major syntax errors resulting in a (562) catastrophic error in the log and the subsequent freezing of the build process, requiring a Build/Cancel in the IDE.
This seems to imply that selected major compilation errors that occur in a thread are somehow leaving the thread in some kind of loop state (ie, using CPU) and never gets to report back to the monitoring process.
This is not a symptom I am familiar with regarding the current compiler. Do you have a test case that reliably reproduces the problem? If so, would you please attach it? A ZIP of a project/solution would be best.
Yes, a test case was an issue I was wrestling with yesterday but it seems that cobbling together something simple doesn't replicate the problem.
It almost seems like the problem is related to the size of the build task, since our proprietary code is made up of 19 projects in the solution with over a thousand source files. My problem occured in the middle of the build (project/thread #10), so possibly anything smaller won't do.
I would probably need to create a test solution with enough projects to force the simultaneous execution of multiple compile threads, which also means the compilations can't be trivial or they'll end too quickly.
Bottom line is that I think the creation of a test case will be difficult. We have a workaround, which is to force a build cancel, so I guess that'll have to do until someone else (preferably at Intel) runs into the problem. I was sort of hoping this was already known and that there would be comments about it, but I guess we're the first.
This same code has been built the same way since IVF 9.x - 11.0 without exhibiting the freeze which only started occuring in 11.1 (specifically 11.1.051, 11.1.046, 11.1.03?).
It almost seems like the problem is related to the size of the build task, since our proprietary code is made up of 19 projects in the solution with over a thousand source files. My problem occured in the middle of the build (project/thread #10), so possibly anything smaller won't do.
I would probably need to create a test solution with enough projects to force the simultaneous execution of multiple compile threads, which also means the compilations can't be trivial or they'll end too quickly.
Bottom line is that I think the creation of a test case will be difficult. We have a workaround, which is to force a build cancel, so I guess that'll have to do until someone else (preferably at Intel) runs into the problem. I was sort of hoping this was already known and that there would be comments about it, but I guess we're the first.
This same code has been built the same way since IVF 9.x - 11.0 without exhibiting the freeze which only started occuring in 11.1 (specifically 11.1.051, 11.1.046, 11.1.03?).
Quoting - longden_loo
Yes, a test case was an issue I was wrestling with yesterday but it seems that cobbling together something simple doesn't replicate the problem.
It almost seems like the problem is related to the size of the build task, since our proprietary code is made up of 19 projects in the solution with over a thousand source files. My problem occured in the middle of the build (project/thread #10), so possibly anything smaller won't do.
I would probably need to create a test solution with enough projects to force the simultaneous execution of multiple compile threads, which also means the compilations can't be trivial or they'll end too quickly.
Bottom line is that I think the creation of a test case will be difficult. We have a workaround, which is to force a build cancel, so I guess that'll have to do until someone else (preferably at Intel) runs into the problem. I was sort of hoping this was already known and that there would be comments about it, but I guess we're the first.
This same code has been built the same way since IVF 9.x - 11.0 without exhibiting the freeze which only started occuring in 11.1 (specifically 11.1.051, 11.1.046, 11.1.03?).
It almost seems like the problem is related to the size of the build task, since our proprietary code is made up of 19 projects in the solution with over a thousand source files. My problem occured in the middle of the build (project/thread #10), so possibly anything smaller won't do.
I would probably need to create a test solution with enough projects to force the simultaneous execution of multiple compile threads, which also means the compilations can't be trivial or they'll end too quickly.
Bottom line is that I think the creation of a test case will be difficult. We have a workaround, which is to force a build cancel, so I guess that'll have to do until someone else (preferably at Intel) runs into the problem. I was sort of hoping this was already known and that there would be comments about it, but I guess we're the first.
This same code has been built the same way since IVF 9.x - 11.0 without exhibiting the freeze which only started occuring in 11.1 (specifically 11.1.051, 11.1.046, 11.1.03?).
Jsut a long shot here -- is the problem possible due to the order of compilation with multiple threads? Do you get the same problem if the compilation is forced to run sequentially in a single thread (painful).
Quoting - longden_loo
Ahh, now that's a question we had all been asking ... whether there was a way to turn off or bypass the multi-threaded processing.
So how do we do that?
So how do we do that?
Tools / Options / Projects and Solutions / Build and Run
Can set maximum number of parallel project builds
Regards,
David
Thanks for that tip. I was able to set the number of processes to "1" so the build proceeded sequentially.
However, the build still locks up at the same point on the same project unless I add the missing module file back into the project's source files list.
However, the build still locks up at the same point on the same project unless I add the missing module file back into the project's source files list.
Quoting - Steve Lionel (Intel)
Does the INCLUDE path include any network shares?
Not that I know of.
The INCLUDE path in the Windows environment only had this:
C:Program FilesMicrosoft Visual Studio .NET 2003SDKv1.1include
... I removed the INCLUDE variable altogether (since I'm on VS2008) with no effect (build still freezes).
The problematic project's properties has "Additional Include Directories", but they are all on the local drive (in the same general folders as the main source). "Ignore Standard Include Path" is set to "no".
Quoting - longden_loo
Thanks for that tip. I was able to set the number of processes to "1" so the build proceeded sequentially.
However, the build still locks up at the same point on the same project unless I add the missing module file back into the project's source files list.
However, the build still locks up at the same point on the same project unless I add the missing module file back into the project's source files list.
If I understand correctly, thehang presents itself on a particular file that has zillions of errors caused by a missing mod file, yes?
I see we fixed one similar problem in Update3, where "too many errors" caused the compiler to hang. Sounds like yours is a close cousin to that one.
Are you willing to let us have the one source file that provokes the hang? Or, give me enough of a "pattern" (if you will) to try and reproduce it in house?
In the meantime, try increasing the error limit for that file (Properties->Fortran->Diagnostics) and see what happens.
thanks --
- Lorri
>>
If I understand correctly, the hang presents itself on a particular file that has zillions of errors caused by a missing mod file, yes?
I see we fixed one similar problem in Update3, where "too many errors" caused the compiler to hang. Sounds like yours is a close cousin to that one.
<<
Maybe. But in fact, when I cancel my frozen build, it reports only 5 lines of errors related to the missing mod file.
I had mentioned that a co-worker was experiencing similar build freezes when one of his project had catastrophic errors caused by syntax. Now he is working with a pre-Update3 version of IVF so possibly his issue is closer to what you describe as fixed in Update3.
>>
Are you willing to let us have the one source file that provokes the hang? Or, give me enough of a "pattern" (if you will) to try and reproduce it in house?
<<
Unfortunately it's proprietary, but we are still trying to isolate a "sanitized" case that will demo the problem.
>>
In the meantime, try increasing the error limit for that file (Properties->Fortran->Diagnostics) and see what happens.
<<
I increased it from 30 (default) to 300 without any effect (still freezes at the same place).
If I understand correctly, the hang presents itself on a particular file that has zillions of errors caused by a missing mod file, yes?
I see we fixed one similar problem in Update3, where "too many errors" caused the compiler to hang. Sounds like yours is a close cousin to that one.
<<
Maybe. But in fact, when I cancel my frozen build, it reports only 5 lines of errors related to the missing mod file.
I had mentioned that a co-worker was experiencing similar build freezes when one of his project had catastrophic errors caused by syntax. Now he is working with a pre-Update3 version of IVF so possibly his issue is closer to what you describe as fixed in Update3.
>>
Are you willing to let us have the one source file that provokes the hang? Or, give me enough of a "pattern" (if you will) to try and reproduce it in house?
<<
Unfortunately it's proprietary, but we are still trying to isolate a "sanitized" case that will demo the problem.
>>
In the meantime, try increasing the error limit for that file (Properties->Fortran->Diagnostics) and see what happens.
<<
I increased it from 30 (default) to 300 without any effect (still freezes at the same place).
I think I've found the cause of my build hangs.
The problem isn't directly due to the absence of a module file during the compilation of the routine that USEs it, rather the missing module file causes a series of other compilation errors, mostly due to undeclared variables that were defined in the missing module.
Very specifically, error #6458 relating to an undefined structure seems to be the killer:
error #6458: This name must be the name of a variable with a derived type (structure type)
This simple main program duplicates the problem, and should result in the build hanging almost immediately. Checking Task Manager at that point should show fortcom running madly. Canceling the build should then show the above error message.
Sample:
implicit none
integer :: n=1
bogus(n)%aa%bb = 1
stop
end
... the problem seems very specific. If I shorten the structure reference to "bogus(n)%aa = 1", the build completes and shows the same error message, but no hanging occurs.
The problem isn't directly due to the absence of a module file during the compilation of the routine that USEs it, rather the missing module file causes a series of other compilation errors, mostly due to undeclared variables that were defined in the missing module.
Very specifically, error #6458 relating to an undefined structure seems to be the killer:
error #6458: This name must be the name of a variable with a derived type (structure type)
This simple main program duplicates the problem, and should result in the build hanging almost immediately. Checking Task Manager at that point should show fortcom running madly. Canceling the build should then show the above error message.
Sample:
implicit none
integer :: n=1
bogus(n)%aa%bb = 1
stop
end
... the problem seems very specific. If I shorten the structure reference to "bogus(n)%aa = 1", the build completes and shows the same error message, but no hanging occurs.
OK, thanks for all that info ...
With only 5 errors, it's pretty clear you're not running into the same "too-many-errors" thing. It really does sound like the compiler is getting itself into a knot somewhere else.
Quoting - longden_loo
I think I've found the cause of my build hangs.
The problem isn't directly due to the absence of a module file during the compilation of the routine that USEs it, rather the missing module file causes a series of other compilation errors, mostly due to undeclared variables that were defined in the missing module.
Very specifically, error #6458 relating to an undefined structure seems to be the killer:
error #6458: This name must be the name of a variable with a derived type (structure type)
This simple main program duplicates the problem, and should result in the build hanging almost immediately. Checking Task Manager at that point should show fortcom running madly. Canceling the build should then show the above error message.
Sample:
implicit none
integer :: n=1
bogus(n)%aa%bb = 1
stop
end
... the problem seems very specific. If I shorten the structure reference to "bogus(n)%aa = 1", the build completes and shows the same error message, but no hanging occurs.
The problem isn't directly due to the absence of a module file during the compilation of the routine that USEs it, rather the missing module file causes a series of other compilation errors, mostly due to undeclared variables that were defined in the missing module.
Very specifically, error #6458 relating to an undefined structure seems to be the killer:
error #6458: This name must be the name of a variable with a derived type (structure type)
This simple main program duplicates the problem, and should result in the build hanging almost immediately. Checking Task Manager at that point should show fortcom running madly. Canceling the build should then show the above error message.
Sample:
implicit none
integer :: n=1
bogus(n)%aa%bb = 1
stop
end
... the problem seems very specific. If I shorten the structure reference to "bogus(n)%aa = 1", the build completes and shows the same error message, but no hanging occurs.
Very cool, thanks!!!
The good news (for a Friday afternoon) is that this seems to be fixed. When I compiled your program with one of our "under development" compilers,I got the same error you did with the simpler case:
F:tests>ifort -nologo u69925.f90
u69925.f90(3): error #6458: This name must be the name of a variable with a derived type (structure type) [BOGUS]
bogus(n)%aa%bb = 1
^
compilation aborted for u69925.f90 (code 1)
As always, I cannot promise update versions/dates, but this looks promising.
- Lorri
