http://bugzilla.novell.com/show_bug.cgi?id=594541
http://bugzilla.novell.com/show_bug.cgi?id=594541#c0 Summary: xbuild dies if a compiler outputs an error with slightly different spacing Classification: Mono Product: Mono: Tools Version: 2.4.x Platform: x86-64 OS/Version: Ubuntu Status: NEW Severity: Normal Priority: P5 - None Component: xbuild AssignedTo: [email protected] ReportedBy: [email protected] QAContact: [email protected] Found By: --- Blocker: --- Created an attachment (id=352956) --> (http://bugzilla.novell.com/attachment.cgi?id=352956) source & project files for test steps User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100214 Ubuntu/9.10 (karmic) Firefox/3.5.8 Xbuild seems to be using an overly specific regex to parse error lines from compilers. The result is that gmcs works fine, but vbnc (which uses almost exactly the same error format, but is lacking two spaces) causes xbuild to crash with a parsing exception if there were any compiler errors at all. Reproducible: Always Steps to Reproduce: 1. Make sure xbuild (2.4.2.3), gmcs (2.4.2.3), and vbnc (2.4.2) are installed. 2. Edit Microsoft.VisualBasic.targets as described in bug 594526, since otherwise nothing will compile. 3. Create a .cs file and a .vb file that each contain a syntax error. 4. Create .csproj and .vbproj projects that each compile their respective file. 5. Run xbuild on each project. Actual Results: The C# project builds as expected, showing the syntax error in the CoreCompile step, but the VB project dies in the CoreCompile step with the following exception: System.FormatException: Input string was not in the correct format at System.Int32.Parse (System.String s) [0x00000] at Microsoft.Build.Utilities.ToolTask.ParseOrigin (System.String origin, System.String& filename, System.Int32& lineNumber, System.Int32& columnNumber, System.Int32& endLineNumber, System.Int32& endColumnNumber) [0x00000] at Microsoft.Build.Utilities.ToolTask.LogEventsFromTextOutput (System.String singleLine, MessageImportance importance) [0x00000] at Microsoft.Build.Utilities.ToolTask.RealExecute (System.String pathToTool, System.String responseFileCommands, System.String commandLineCommands) [0x00000] at Microsoft.Build.Utilities.ToolTask.ExecuteTool (System.String pathToTool, System.String responseFileCommands, System.String commandLineCommands) [0x00000] at Microsoft.Build.Utilities.ToolTask.Execute () [0x00000] at Microsoft.Build.BuildEngine.TaskEngine.Execute () [0x00000] at Microsoft.Build.BuildEngine.BuildTask.Execute () [0x00000] If you edit the .vb file to remove the syntax error, it builds fine. But if there is *any* error of any kind in the .vb file, xbuild crashes with the same exception as above (and does not tell you what the error was). Expected Results: Xbuild would report the compiler error and not crash. Running gmcs and vbnc outside of xbuild shows a slight difference in the format of their error output: gmcs: $FILENAME.cs($LINE,$COLUMN): error CS$ERRNUM: $ERRORDESC vbnc: $ABSOLUTEPATH/$FILENAME.vb ($LINE,$COLUMN) : Error VBNC$ERRNUM: $ERRORDESC The FormatException suggests that xbuild is trying to parse out either the line/column numbers or the error number, and failing because its regex doesn't work for the vbnc format. I'm calling this an xbuild bug rather than a vbnc bug, because the format difference is very slight and looks like it still ought to be parseable - and in any case, it seems like if xbuild sees something it doesn't know how to parse, it could just display it as is rather than crashing. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
