-
Notifications
You must be signed in to change notification settings - Fork 164
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
Oom alloc #463
base: master
Are you sure you want to change the base?
Oom alloc #463
Conversation
Added another example that OOMs, hasn't been fixed yet, I'm working around it for my usecase by using unstable |
Thanks! |
Do you mean a comment explaining the last OOM file that was added? |
17fc324
to
1ffc325
Compare
I've added a FIXME to the function call that OOMs, if this was not what was meant please advise further. |
Curious whether you know anything about the unknown record types as mentioned in #462. |
When reading a PtgStr 2.5.198.89 the cch byte of ShortXLUnicodeString indicates the number of characters in the string. The error here is twofold: 1. The byte buffer holding the string characters in prematurely truncated before calling fn read_unicode_string_no_cch() based on cch, although the correct length in bytes can only be known inside fn read_unicode..() after checking the fHighByte flag. The fix is to not truncate the buffer at all pass it in its entirety so that fn read_unicode..() may decide how many bytes to read. 2. The second error then advances the offset into the buffer based on this erroneous length, which later leads to crashes.
…prevent OOM allocation due to overflow
…e, otherwise this will crash
Was it intentional that
fn from_sparse
assumes cells are in(row, col)
order? This test example demonstrates this is not always the case and OOM allocates due to an overflow.Based on #462restructured history