Status: Closed (View Workflow)
Hudson version : 1.336
Warnings version : 2.14
Gcc version : 3.4.6
OS : Linux Red Hat
During warnings parsing, the gcc warnings are not correctly detected.
A gcc warnings is seen as an error and the build is set to failed (threshold set to 1 for error)
Note that it was working correctly with Hudson 308 and Warnings 2.8
I isolated the problem in gcc log file.
You can find attached :
- gcc log file
- 2 C++ file associated with the log
To reproduce the problem:
- Create a Job Free Style
- Copy in the workspace the three attached files
- Activate the Scan of Warnings on the log file
- An error is incorrectly detected and failing the build (instead of detecting a warning)
- By clicking on the detected error, the following exception is displayed:
01 hudson.util.IOException2: remote file operation failed
02 at hudson.FilePath.act(FilePath.java:677)
03 at hudson.FilePath.act(FilePath.java:665)
04 at hudson.FilePath.copyTo(FilePath.java:1292)
05 at hudson.plugins.warnings.util.HealthAwarePublisher.copyFilesWithAnnotationsToBuildFolder(HealthAwarePublisher.java:187)
06 at hudson.plugins.warnings.util.HealthAwarePublisher.perform(HealthAwarePublisher.java:144)
07 at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
08 at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:577)
09 at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:563)
10 at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:551)
11 at hudson.model.Build$RunnerImpl.post2(Build.java:152)
12 at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:535)
13 at hudson.model.Run.run(Run.java:1199)
14 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
15 at hudson.model.ResourceController.execute(ResourceController.java:88)
16 at hudson.model.Executor.run(Executor.java:123)
17 Caused by: java.io.FileNotFoundException: In file included from my_class.cpp (No such file or directory)
18 at java.io.FileInputStream.open(Native Method)
19 at java.io.FileInputStream.<init>(FileInputStream.java:106)
20 at hudson.FilePath$30.invoke(FilePath.java:1296)
21 at hudson.FilePath$30.invoke(FilePath.java:1292)
22 at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2072)
23 at hudson.remoting.LocalChannel.call(LocalChannel.java:45)
24 at hudson.FilePath.act(FilePath.java:672)
25 ... 14 more
26 Can't copy file from workspace to build folder: workspace=In file included from my_class.cpp, build folder=/localdata/hudson/jobs/Hudson_Issues/builds/2010-03-29_01-34-18/workspace-files/958509f5.tmp
- depends on
JENKINS-4753 gcc warnings not parsed correctly
The problem is still present by using the following configuration:
Static Analysis Utilities : 1.4
Warnings Plug-in : 3.4
Note that by changing the parser from GCC to GCC4, the log is correctly parsed
which is strange because I am using GCC 3.4.6 and not GCC 4.x
But when the issue is fixed with in the new GCC parser why don't you use it? The old parser will not be supported anymore. Maybe I should change the name of the new parser...
If the new GCC4 parser is the official GCC parser supporting all GCC version including old one like 3.4.x, yes it should be rename and the old one shall be removed to avoid ambiguity.
But, if the goal of GCC4 parser is only to support the GCC version 4.x, the old GCC parser shall continue to be maintained and renamed GCC3, istn't it ?
I think the new parser works with 3.x, too. It's just a new parser. I'm not sure if still someone uses the old parser (I don't use GCC at all). So maybe the best thing is to let both parsers co-exist and change the names. However, currently the display name is used to identify the parser, so changing the name is somewhat complicated without breaking existing jobs...
It is OK for me.
I will create tickets by mentioning the GCC (eg. 3.4.x) if I found some issues on this new parser
NB: Could you update the Wiki page to mention the specificity of the two GCC parsers ?
This has been fixed already and is part of the upcoming release 3.4.