-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Parse] Tweak a utility function that relies on reading past the end #19230
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
Conversation
cc @johnno1962. Here's my alternate solution to #19219, which might fix your problem there too. @swift-ci Please asan test |
@swift-ci Please test |
@swift-ci Please test compiler performance |
Uh, this ASan failure in SILCombine isn't related to what I was fixing. @eeckstein? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! This looks good. (after resolving the conflict)
Build comment file:Compilation-performance test failed |
653a198
to
ce4c576
Compare
@swift-ci Please smoke test |
Lexer::getEncodedStringSegment (now getEncodedStringSegmentImpl) assumes that it can read one byte past the end of a string segment in order to avoid bounds-checks on things like "is this a \r\n sequence?". However, the function was being used for strings that did not come from source where this assumption was not always valid. Change the reusable form of the function to always copy into a temporary buffer, allowing the fast path to continue to be used for normal parsing. Caught by ASan! rdar://problem/44306756
@swift-ci Please test compiler performance |
Build comment file:Compilation-performance test failed |
@jrose-apple Which asan failure in SILCombine failure? |
@eeckstein https://ci.swift.org/view/Pull%20Request/job/swift-PR-osx-ASAN-test/49/ log
|
@swift-ci Please test compiler performance |
@swift-ci Please asan test |
1 similar comment
@swift-ci Please asan test |
@swift-ci Please test compiler performance |
That's a lot of failures, enough that I'm not sure I can trust the results again. Still, this fixes an out-of-bounds issue, so I'm going to merge it. |
Lexer::getEncodedStringSegment
(nowgetEncodedStringSegmentImpl
) assumes that it can read one byte past the end of a string segment in order to avoid bounds-checks on things like "is this a\r\n
sequence?". However, the function was being used for strings that did not come from source where this assumption was not always valid. Change the reusable form of the function to always copy into a temporary buffer, allowing the fast path to continue to be used for normal parsing.Caught by ASan!
rdar://problem/44228891