Parser locks up on long input lines

[mdierolf]

The attached test code fails to parse the attached XML document in a reasonable timeframe:
failing.zip

The issue causing this appears to be a regular expression to split the XML on newlines, which either never returns, or is incredibly slow to return:

At: xmldom/lib/sax.js:69:

function position(p,m){
  while(p>=lineEnd && (m = linePattern.exec(source))){
   lineStart = m.index;
   lineEnd = lineStart + m[0].length;
   locator.lineNumber++;
   //console.log('line++:',locator,startPos,endPos)
  }
  locator.columnNumber = p-lineStart+1;
 }
 var lineStart = 0;
 var lineEnd = 0;
 var linePattern = /.*(?:\r\n?|\n)|.*$/g

It appears that the solution would be to re-engineer the parser to process the XML in stream mode, not by splitting lines with a regular expression

[brodybits]

I have added the needs-investigation and help wanted labels.

It appears that the solution would be to re-engineer the parser to process the XML in stream mode
[...]

I am adding reference to issue #55 to replace lib/sax.js. I suspect there should be an existing SAX parser that we can reuse to both avoid bugs on our side and reduce the maintenance burden.

[karfau]

After fixing duplicate attributes in the provided xml sample (which fails since 0.5.0) I could successfully parse the file when running against master. I assume this was also fixed by normalizing all kinds of line breaks, which landed in #314 and will be part of the 0.8.0 release.