jaxp
  1. jaxp
  2. JAXP-68

Infinite do-while loop in XMLDocumentScannerImpl$PrologDriver.next

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: www
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      68

      Description

      It appears that the do-while loop in XMLDocumentScannerImpl$PrologDriver.next
      causes an infinite loop since there are if-else conditions that do not change
      the "scanner state". Similar code in XercesJ-2
      XMLDocumentScannerImpl$PrologDispather.dispatch appears to have corrected the
      problem.

      Partial thread dump from JDK 1.6.0_15 (although current source code in JAXP
      1.4.4 does not appear to have changed):
      "validateClockAction-9197" daemon prio=10 tid=0x00002aab84013800 nid=0x780f
      runnable [0x00000000414a6000]
      java.lang.Thread.State: RUNNABLE
      at
      com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next
      (XMLDocumentScannerImpl.java:931)
      at
      com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
      (XMLDocumentScannerImpl.java:648)
      at
      com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
      (XMLNSDocumentScannerImpl.java:140)
      at
      com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next
      (XMLStreamReaderImpl.java:548)
      at org.codehaus.xfire.soap.handler.ReadHeadersHandler.invoke
      (ReadHeadersHandler.java:44)

      Source excerpt from JAXP:
      do {
      switch (fScannerState) {
      case SCANNER_STATE_PROLOG: {
      fEntityScanner.skipSpaces();
      if (fEntityScanner.skipChar('<'))

      { setScannerState(SCANNER_STATE_START_OF_MARKUP); }

      else if (fEntityScanner.skipChar('&'))

      { setScannerState(SCANNER_STATE_REFERENCE); }

      else

      { setScannerState(SCANNER_STATE_CONTENT); }

      break;
      }

      case SCANNER_STATE_START_OF_MARKUP: {
      fMarkupDepth++;

      if (fEntityScanner.skipChar('?'))

      { setScannerState(SCANNER_STATE_PI); }

      else if (fEntityScanner.skipChar('!')) {
      if (fEntityScanner.skipChar('-')) {
      if (!fEntityScanner.skipChar('-'))

      { reportFatalError("InvalidCommentStart", null); }

      setScannerState(SCANNER_STATE_COMMENT);
      } else if (fEntityScanner.skipString(DOCTYPE)) {
      setScannerState(SCANNER_STATE_DOCTYPE);
      Entity entity =
      fEntityScanner.getCurrentEntity();
      if(entity instanceof Entity.ScannedEntity)

      { fStartPos=((Entity.ScannedEntity) entity).position; }

      fReadingDTD=true;
      if(fDTDDecl == null)
      fDTDDecl = new XMLStringBuffer();
      fDTDDecl.append("<!DOCTYPE");

      } else

      { reportFatalError ("MarkupNotRecognizedInProlog", null); >>>>>no change in fScannerState }

      } else if (XMLChar.isNameStart
      (fEntityScanner.peekChar()))

      { setScannerState(SCANNER_STATE_ROOT_ELEMENT); setDriver(fContentDriver); //from now onwards this would be handled by fContentDriver,in the same next() call return fContentDriver.next(); }

      else

      { reportFatalError("MarkupNotRecognizedInProlog", null); >>>>>no change in fScannerState }

      break;
      }
      }
      } while (fScannerState == SCANNER_STATE_PROLOG || fScannerState
      == SCANNER_STATE_START_OF_MARKUP );

        Activity

        Hide
        stevehale added a comment -

        Unfortunately I have not been able to capture a test case, and our client is now using the Woodstox StAX implementation to avoid this issue. I could not use your modified jaxp.jar even if you sent it to me. However I do not believe it is an issue with "continue-after-fatal-error", but I don't have much else to go on.

        The only thing I have read recently is some mention of a possible infinite loop caused by a premature EOF since SJSXP avoids throwing exceptions after receiving an EOF (at least according to what I read). I have not persued this possibility in any way, it was just something I read, so thought it might help.

        Show
        stevehale added a comment - Unfortunately I have not been able to capture a test case, and our client is now using the Woodstox StAX implementation to avoid this issue. I could not use your modified jaxp.jar even if you sent it to me. However I do not believe it is an issue with "continue-after-fatal-error", but I don't have much else to go on. The only thing I have read recently is some mention of a possible infinite loop caused by a premature EOF since SJSXP avoids throwing exceptions after receiving an EOF (at least according to what I read). I have not persued this possibility in any way, it was just something I read, so thought it might help.
        Hide
        kln550 added a comment -

        During load tests,we are still seeing infinite loop issue with JDK 1.6 update 26 stax implementation.Any resolutions for this issue.

        Show
        kln550 added a comment - During load tests,we are still seeing infinite loop issue with JDK 1.6 update 26 stax implementation.Any resolutions for this issue.
        Hide
        stevehale added a comment -

        kln550, I could never capture a test case in DEV environment so it makes sense that this only happens under load. Without a way to reproduce it, no one would look into it. Our workaround was to use Woodstox StAX imnplementation instead of that provided by the JDK within JAXP (see prior entries), although that would have been preferred. Maybe it will be researched if you can provide more details on how to reproduce it.

        Show
        stevehale added a comment - kln550, I could never capture a test case in DEV environment so it makes sense that this only happens under load. Without a way to reproduce it, no one would look into it. Our workaround was to use Woodstox StAX imnplementation instead of that provided by the JDK within JAXP (see prior entries), although that would have been preferred. Maybe it will be researched if you can provide more details on how to reproduce it.
        Hide
        tbutcher added a comment -

        We are seeing very similar symptoms with on a high-load live website. We are using Xerces to 2.10.0. The thread dump is similar but we are not using stax.

        The problem seems to occur only under productions conditions and we have not been able to reproduce it in a test environment. We need to restart appservers occasionally when the number of looping threads is large enough to cause a significant CPU load.

        We are not using 'continue-after-fatal-error'.

        Show
        tbutcher added a comment - We are seeing very similar symptoms with on a high-load live website. We are using Xerces to 2.10.0. The thread dump is similar but we are not using stax. The problem seems to occur only under productions conditions and we have not been able to reproduce it in a test environment. We need to restart appservers occasionally when the number of looping threads is large enough to cause a significant CPU load. We are not using 'continue-after-fatal-error'.
        Hide
        Joe Wang added a comment -

        Thanks for the information.

        Are you using Xerces 2.10 only, or have you tried with/without the Xerces jar? If it's Xerces 2.10 only, have you reported the issue to Apache?

        Thanks.

        Show
        Joe Wang added a comment - Thanks for the information. Are you using Xerces 2.10 only, or have you tried with/without the Xerces jar? If it's Xerces 2.10 only, have you reported the issue to Apache? Thanks.

          People

          • Assignee:
            jaxp-issues
            Reporter:
            stevehale
          • Votes:
            4 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: