Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error while parsing negative floats at the end of the input buffer #146

Closed
rjmac opened this issue Aug 1, 2014 · 5 comments
Closed

Error while parsing negative floats at the end of the input buffer #146

rjmac opened this issue Aug 1, 2014 · 5 comments
Milestone

Comments

@rjmac
Copy link

rjmac commented Aug 1, 2014

I've been doing some randomized testing, and it looks like _parseFloat in ReaderBasedJsonParser has a bug that is triggered when parsing negative numbers with exponents whose sign character appears immediately before the end of the input buffer. At line 923 of the current master:

            // Sign indicator?
            ch = (int) _inputBuffer[ptr++];
            if (ch == INT_MINUS || ch == INT_PLUS) { // yup, skip for now
                if (ptr >= inputLen) {
                    _inputPtr = startPtr;
                    return _parseNumber2(false, startPtr);
                }
                ch = (int) _inputBuffer[ptr++];
            }

It looks like the intent of this is to fall back to a slow path in that case, but _parseNumber2 gets passed "false" in the neg parameter, so it doesn't expect to see the initial sign character and throws a "missing integer part" parse error. I think passing neg there instead of false would fix it.

Here's a reproducing case:

    char[] arr = new char[50005];
    for(int i = 0; i != 50000; ++i) {
      java.util.Arrays.fill(arr, 0, i, ' ');
      arr[i] = '-';
      arr[i + 1] = '1';
      arr[i + 2] = 'e';
      arr[i + 3] = '-';
      arr[i + 4] = '1';
      CharArrayReader r = new CharArrayReader(arr, 0, i + 5);
      new JsonFactory().createParser(r).nextToken();
    }

At about 4000 iterations in, the bug will trigger.

@cowtowncoder
Copy link
Member

Thank you for doing all the detective work. Boundary problems are tricky, which is why this one appears to have survived this long...

cowtowncoder added a commit that referenced this issue Aug 8, 2014
@cowtowncoder
Copy link
Member

Actually, never mind. This is 2.4-only regression, which explains part of the problem; 2.3.x is not affected.
I can reproduce it on master, and will fix for 2.4.2.

@cowtowncoder cowtowncoder added this to the 2.4.2 milestone Aug 8, 2014
@cowtowncoder
Copy link
Member

FWIW, only affects reader-backed inputs (not byte-backed), and versions 2.4.0, 2.4.1. Fixed in 2.4.2.
Regression due to attempts to optimize number parsing; while 2.4 is measurably faster than 2.3, it is unfortunate that there was this regression.

@rjmac
Copy link
Author

rjmac commented Aug 11, 2014

Looks like the test and the release notes got committed, but the actual fix didn't.

cowtowncoder added a commit that referenced this issue Aug 11, 2014
@cowtowncoder
Copy link
Member

@rjmac whops. Fixed now.

ThorbenLindhauer added a commit to camunda/camunda-spin that referenced this issue May 13, 2015
ThorbenLindhauer added a commit to camunda/camunda-spin that referenced this issue May 13, 2015
menski added a commit to camunda/camunda-bpm-platform that referenced this issue May 19, 2015
venetrius pushed a commit to camunda/camunda-bpm-platform that referenced this issue Mar 20, 2024
venetrius pushed a commit to camunda/camunda-bpm-platform that referenced this issue Mar 21, 2024
venetrius pushed a commit to camunda/camunda-bpm-platform that referenced this issue Apr 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants