Closed Bug 112943 Opened 23 years ago Closed 15 years ago

Distance() hangs in copy_string with iterators

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: hjtoi-bugzilla, Assigned: jag+mozilla)

References

Details

(Keywords: hang) 

While working on bug 110544, I made quite a heavy use of string iterators and
CopyUnicodeTo() function. With one particular testcase I would cause
CopyUnicodeTo() hang. It seemed like there was a string consisting of multiple
buffers, and the hang happened when Distance() called copy_string().

I then changed CopyUnicodeTo() to Substring(), and now I get hang with trivially
simple case.

I would be happy to know if I am doing something wrong. This is practically
blocking me from landing the fix to bug 110544.

To test, add the following function to nsHTMLTokens.cpp:

static
nsresult ConsumeStrictComment(nsScanner& aScanner, nsString& aString) {
  aString.Truncate();

  // <!--[... -- ... -- ...]*-->
  /*********************************************************
    NOTE: This algorithm does a fine job of handling comments
          when they're formatted per spec, but if they're not
          we don't handle them well.
   *********************************************************/
  nsReadingIterator<PRUnichar> end, current;
  aScanner.EndReading(end);
  aScanner.CurrentPosition(current);

  nsReadingIterator<PRUnichar> currentEnd = end, beginData = end;
  PRBool balancedComment = PR_TRUE;

  while (FindInReadable(NS_LITERAL_STRING("--"), current, currentEnd)) {
    current.advance(2);
    if (beginData == end) {
      beginData = current;
    }
    balancedComment = !balancedComment; // We need to match '--' with '--'
    
    if (*current == kGreaterThan && balancedComment) {
      // done
      current.advance(-2);
      if (beginData != current) { // protects from <!---->
        aString = Substring(beginData, current); // <= HANG!
      }
      current.advance(3);
      aScanner.SetPosition(current);
      return NS_OK;
    } else {
      // Continue after the last '--'
      currentEnd = end;
    }
  }
  
  return kEOF; // not really an nsresult, but...
}

and change the single caller of ConsumeStrictComment():

-    result=ConsumeStrictComment(aChar,aScanner,mTextValue);
+    result=ConsumeStrictComment(aScanner,mTextValue);
Then start mozilla so that the first file it tries to open is one like below:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<!--a-->
jag mentioned that this might have been fixed. I pulled today, but the same
thing still occurs :(
giving up ancient string bugs to the new string owner.  jag, you'll want to sort
through these and see which ones still apply and go with or against the
direction in which you intend strings evolve
Assignee: scc → jaggernaut
QA Contact: jag → string
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
Component: String → XPCOM
You need to log in before you can comment on or make changes to this bug.