-
-
Notifications
You must be signed in to change notification settings - Fork 798
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
Comments
Thank you for doing all the detective work. Boundary problems are tricky, which is why this one appears to have survived this long... |
Actually, never mind. This is 2.4-only regression, which explains part of the problem; 2.3.x is not affected. |
FWIW, only affects reader-backed inputs (not byte-backed), and versions 2.4.0, 2.4.1. Fixed in 2.4.2. |
Looks like the test and the release notes got committed, but the actual fix didn't. |
@rjmac whops. Fixed now. |
- avoids Jackson bug FasterXML/jackson-core#146 related to CAM-3885
- avoids Jackson bug FasterXML/jackson-core#146 related to CAM-3885
- avoids Jackson bug FasterXML/jackson-core#146 related to CAM-3885
- avoids Jackson bug FasterXML/jackson-core#146 related to CAM-3885
- avoids Jackson bug FasterXML/jackson-core#146 related to CAM-3885
I've been doing some randomized testing, and it looks like
_parseFloat
inReaderBasedJsonParser
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:It looks like the intent of this is to fall back to a slow path in that case, but
_parseNumber2
gets passed "false" in theneg
parameter, so it doesn't expect to see the initial sign character and throws a "missing integer part" parse error. I think passingneg
there instead of false would fix it.Here's a reproducing case:
At about 4000 iterations in, the bug will trigger.
The text was updated successfully, but these errors were encountered: