Ticket #370 (new defect)

Opened 3 years ago

Last modified 3 years ago

Some MD/XS projects trigger a COBRA INTERNAL ERROR/FormatException

Reported by: torial Owned by:
Priority: major Milestone: Cobra 0.9
Component: Cobra Compiler Version: 0.9.6
Keywords: Cc: thriwkin@…, ramon.rocha@…


On Mac OSX 10.8.5 , with Cobra 0.9.6, using Mono 3.4.0

I get the following Internal Error
/Library/Frameworks/Mono.framework/External/xbuild/Cobra/Cobra.targets: error : error: COBRA INTERNAL ERROR / FormatException? / Input string was not in the correct format

Task "CobraCompiler?" execution -- FAILED
Done building target "CoreCompile?" in project "/Users/klickle/Downloads/CherryCobbler/CherryCobbler/CherryCobbler.cobraproj".-- FAILED

I have recently added a file (in progress of making a port of some python code), and the behavior did not manifest until I started on this file.


Spam.cobra Download (2.0 KB) - added by torial 3 years ago.
File that seems to cause internal error

Change History

Changed 3 years ago by torial

File that seems to cause internal error

Changed 3 years ago by torial

I went through and commented out each function, and this is the one that seems to be causing problems:

	def ngram(n as int, toParse as String) as String*
		"""Returns all n grams from toParse after normalizing"""
		filtered = .normalize(toParse)
		for start in filtered.length - n +1
			yield String.join(filtered[start:start+n]) to !

I will rewrite my logic here, but probably worth improving the compiler to catch this.

Changed 3 years ago by thriwkin

  • cc thriwkin@… added

The file "Spam.cobra" does not cause the COBRA INTERNAL ERROR.

1. Additional infos needed
The error message comes from xbuild.exe or msbuild.exe,
and cannot be reproduced with the file "Spam.cobra" alone.

Additionally, at least this file would be necessary:


2. Possible sources of the failure
Presumably you use this IDE-addin for MonoDevelop/XamarinStudio:
"MonoDevelop.CobraBinding" (

If so, then these are the possible sources of the failure:
- the project file, e.g. "CherryCobbler.cobraproj", generated by the IDE/IDE-addin,
- the .targets file, "Cobra.targets", supplied by the IDE-addin,
- the assembly with the MSBuild Task, "Cobra.MSBuild.dll", supplied by the IDE-addin.

3. The file "Spam.cobra" does not cause the COBRA INTERNAL ERROR

If I compile "Spam.cobra" with this commandline

cobra -target:lib  -compile Spam.cobra

then the compiler generates correct error messages only,
and it will compile without any errors after these modifications:

  • line 6: error: Cannot find namespace "CherryCobbler.Common".
    # change this
         use CherryCobbler.Common
    # to
        # use CherryCobbler.Common
  • line 33: error: The call is ambiguous ...
    # change this
        yield String.join(filtered[start:start+n]) to !
    # to
        yield String.join('', filtered[start:start+n]) to !
    # (then it is syntactically correct)
    # or change to
        yield filtered[start:start+n]
    # (then it is semantically correct, 
    #  since `.normalize` returns a String, not a String*. )
  • line 15: warning: The first statement of an "init" cue ...
    # change this
        cue init
    # to
        cue init

NOTE: I think that it would be very interesting to discuss your project in the Forum:
- porting to Cobra the Python program "Gibberish-Detector"

Changed 3 years ago by nerdzero

  • cc ramon.rocha@… added

What will be helpful here is knowing what command line options the add-in is generating. This will be visible in the "Build Output" pane under the "Target CoreCompile:" section.

Also, just to clarify, although Cobra.targets and Cobra.MSBuild.dll were primarily developed in support of the MD add-in, they are not part of the add-in itself and are installed at the same time as the Cobra compiler.

Changed 3 years ago by thriwkin

Yes, correct, the files "Cobra.targets" and "Cobra.MSBuild.dll" are part of the Cobra compiler installation.
And furthermore, they can be used without the IDE-addin, e.g. with another IDE-addin, or by writing the project file with an editor and calling xbuild.exe or msbuild.exe on the commandline.
And these files seem to be identical in the current Cobra version (svn:3116) and Cobra 0.9.6, which the bug reporter used.

So, maybe this formulation is more precise:

Possible sources of the failure are

  • the project file, e.g. "CherryCobbler.cobraproj",
  • the "Cobra.targets" file,
  • the MSBuild Task in "Cobra.MSBuild.dll" (source in "CobraCompiler.cobra"),

Changed 3 years ago by thriwkin

Second musings
After having inspected the source code of the MSBuild task and the compiler,
I think now:

The failure

  • is not caused by something in the file "Spam.cobra";
  • is not caused by the compilation context
    (Cobra.MSBuild.dll, Cobra.targets, IDE-addin, X.cobraproj);
  • is caused by something in an unkown file "X.cobra" which is not posted.


  • All "COBRA INTERNAL ERROR" are InternalError exceptions, thrown in def _compile1 in class Compiler.
  • If the compilation context would produce an invalid commandline,
    then the method Compiler._compile1 would not be called.
  • The reported error message
    " COBRA INTERNAL ERROR /FormatException/ Input string was not in the correct format."
    shows that the bug causes a FormatException,
    thrown for example by int.parse("...").

Since the compiler source contains a lot of such expressions (int.parse),
maybe the failure

  • is caused by something in a compiled source file
  • which causes that the compiler executes an x.parse (x: int, uint, int64, uint64, ...) such that a FormatException is thrown,
  • which is catched in Compiler._compile1 and converted to an InternalError exception,
  • which is reported as the above COBRA INTERNAL ERROR.

But this something
- is not contained in the source files posted,
- and I cannot invent it.

I think, this ticket can be closed, because the bug cannot be reproduced.

Changed 3 years ago by nerdzero

  • summary changed from Internal Error to Some MD/XS projects trigger a COBRA INTERNAL ERROR/FormatException

Good investigative work, thriwkin. It sounds like unless torial provides a zip of the entire project folder that demonstrates the issue, we won't be able to track this one down easily.

Note: See TracTickets for help on using tickets.