You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the IonParser::getText() method, there is a call to the IonReader::stringValue() which is served by an Amazon implementation of IonReaderTextSystemX. The method does throw UnknownSymbolException if the symbol id cannot be resolved. But it also contains some assert statements which throw AssertionError when the resolved symbol id is 0 or negative. The AssertionError`` is not handled and is thrown to the users unexpectedly.
@OverridepublicStringgetText() throwsIOException
{
if (_currToken != null) { // null only before/after document
......
caseVALUE_STRING:
try {
// stringValue() will throw an UnknownSymbolException if we're// trying to get the text for a symbol id that cannot be resolved.return_reader.stringValue();
} catch (UnknownSymbolExceptione) {
throw_constructError(e.getMessage(), e);
}
......
returnnull;
}
The simplest fix is to also catch the AssertionError, the same as the UnkonwnSymbolException. In general, AssertionError should be internal use only and should be wrapped and avoided by throwing directly to the users. Not sure if it is meant to not handle it in this situation.
cowtowncoder
changed the title
IonReader classes contain assert statement which could throw unexpected AssertionErrorIonReader classes contain assert statement which could throw unexpected AssertionErrorDec 6, 2023
Thank you @arthurscchan ! I merged the PR, made some minor changes (not to logic but just testing, message) and it should go in 2.17. And Fuzzer can hopefully clear up one of crash cases.
In the
IonParser::getText()
method, there is a call to theIonReader::stringValue()
which is served by an Amazon implementation ofIonReaderTextSystemX
. The method does throwUnknownSymbolException
if the symbol id cannot be resolved. But it also contains some assert statements which throwAssertionError
when the resolved symbol id is 0 or negative. The AssertionError`` is not handled and is thrown to the users unexpectedly.The simplest fix is to also catch the
AssertionError
, the same as theUnkonwnSymbolException
. In general, AssertionError should be internal use only and should be wrapped and avoided by throwing directly to the users. Not sure if it is meant to not handle it in this situation.We found this issue by OSS-Fuzz and it is reported in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=64721.
The text was updated successfully, but these errors were encountered: